Nextcloud -- [authz_core:error] AH01630: client denied by server configuration: /var/www/apps (dav/cloud/etc)

Troubleshooting
21

@MichaIng : BTW, there is a related bug report: AH01630: client denied by server configuration: /var/www/nextcloud/config · Issue #15688 · nextcloud/server · GitHub

In that report, it notes that this behavior is quite possibly inherent in the way the clients are designed to query the server using rewrites to direct requests from URLs like “/ocs/v1.php/config?format=json” to the proper directory in Apache. There is a whole bunch of rewrite logic in the .htaccess file to this effect. Again, why these requests are going to root instead of /nextcloud is beyond me, and is really central to the crux here. I know you’ve devolved to blaming me for whatever is going on, but really, you guys installed Nextcloud at /nextcloud and not in the root folder, so whatever is going on should concern you.

Here’s the relevant portions of the .htaccess

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT} DavClnt
  RewriteRule ^$ /remote.php/webdav/ [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
  RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

AddDefaultCharset utf-8
Options -Indexes
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /nextcloud/
ErrorDocument 404 /nextcloud/
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff2?|ico|jpg|jpeg|map|webm|mp4|mp3|ogg|wav|wasm|tflite)$
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update\.php
  RewriteCond %{REQUEST_FILENAME} !/core/img/(favicon\.ico|manifest\.json)$
  RewriteCond %{REQUEST_FILENAME} !/(cron|public|remote|status)\.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v(1|2)\.php
  RewriteCond %{REQUEST_FILENAME} !/robots\.txt
  RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteCond %{REQUEST_FILENAME} !/richdocumentscode(_arm64)?/proxy.php$
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /nextcloud
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

What I have not tried, and I intend to, is reinstalling a fresh copy of Nextcloud as I have updated this instance across at least two major versions. Perhaps this was already remedied.

22

The linked issue should have been fixed by Remove request to config for userVisibleURL. by allexzander · Pull Request #3552 · nextcloud/desktop · GitHub and before that the request should have gone to /var/www/nextcloud/config and not /var/www/*, and you see this not for the config dir (?) but for a bunch of other directories. The linked issue was about a request to nextcloud/ocs/v1.php/config?format=json, there the /config part came from, so at first view it is not obviously related (while also your clients do similar requests with /apps element in URI).

Why do you not catch 404 logs then? However, as said, it can be seen as a security measure, that is right.

This is not my software, we are just implementing an install option for it. However, I know in which order configs are loaded, and that they are basically merged, not overriding each other. I was asking whether/why you are sure about it. I am not sure in your case, since you didn’t post the file paths of your configs. Basically, apache2.conf is loaded, and if its content is not changed in this regards, it contains the include directives in this order:

  • ports.conf
  • mods-enabled
  • conf-enabled
  • sites-enabled

Within each directory, configs are loaded in alphanumerical order. So if you have sites-enabled/000-default-le-ssl.conf and sites-enabled/default-ssl.conf, the the second will in case override directives within the first, which means you would have a wrong DocumentRoot and dummy ServerAdmin and probably more depending on the bottom of the file. Since generally it works (with HTTPS?), either an assumption is wrong or _default_:443 does not equal *:443 for every request. In any case, default-ssl.conf should be disabled.

But you did change other configs. So I can only repeat myself, as this is the only way we can know exactly what causes your /var/www/* requests which only you see while thousands of other DietPi Nextcloud users do not: Test with a completely default setup without any modification and start in small steps from there. If the only effective change in your case is blocking /var/www/* by default, try whether you can fix the 403 requests by commenting the related section. Then we have something to reasonably work with and can try to understand how this can make a difference, and whether there is indeed a quirk within the Nextcloud rewrite rules (when located in a sub directory of the webroot).

The .htaccess is updated automatically on Nextcloud updates, so it is always up-to-date and a reinstall wouldn’t change something.

I’m sorry for my harsh sounding words, but as I repeated several times, you are the only one facing such issues and you have quite some changes done to your Apache2 which are not all transparent to me. So your config makes the difference, and as long as you do not first try to revert your customisations, it does not make sense to assume that our implementation or Nextcloud itself is to blame. I do not say that there is nothing we or Nextcloud can improve to be more compatible with Apache setups like yours, but without knowing at least which exact difference is causing the behaviour, we can only tap in the dark.

Nextcloud in a sub directory is a perfectly supported and documented option, so there is no reason to assume this causes any issues, and again it never did for thousands of users.

23

Before this discussion can and should go any further, we should address the real issue at the heart of everything:

why are any requests from the clients going to /var/www and not /var/www/nextcloud? The SINGLE change I made was to simply lock down the /var/www directory – this would NOT stop any requests going to that directory, it would simply block them from getting through. My change to the base Apache config merely exposes the issue, it didn’t cause it.

So, let’s answer that question first, and then we can move on. Likely, in answering that question, we can fix the issue, too.

24

OK, let’s also get past this narrative that I “changed a bunch of configs” and put that behind us, too. I’m tired of blasting on repeat that I did not touch any configs save one.

Here, I have produced screenshots of my relevant directories where the configs exist for my server. The file highlighted in yellow below is the ONLY config I have changed. All of these configs were installed by scripts within your operating system.

image
image769×61 2.73 KB

image
image1020×65 2.7 KB

image

Now, here’s the exact code that I changed:

Now, can we please move past the narrative that I changed a bunch of configs? I literally took a text editor to this one file, and made this one change. That’s it!

25

I’m not sure whether it is correct what you derive. If you do not deny requests to non-existing directories in /var/www, you should instead see 404 errors.

26

How does this answer this question:

Why are any requests from Nextcloud clients going to /var/www and not /var/www/nextcloud?

?

27

Okay, I tried it now on my personal instance and can replicate the issue by only commenting the /var/www block. For the future: This kind of verification from your end on an otherwise fresh unmodified install would be what would render all discussion obsolete :wink:. From all you posted, including the default-ssl.conf and your own /var/www/* blocks this is was only a guess.

It doesn’t but it is a waste of time to start investigation without knowing for sure which exact change is causing it. This was all I tried to make clear from one of my firsts posts on.

28

Great! You can replicate the issue! Now, let’s work on fixing it. Whew.

Let’s start by answering the question: “Why are any requests from the Nextcloud clients going to /var/www instead of /var/www/nextcloud?”

That should be where we focus. If this is outside the scope of your OS, then so be it, but I started here first because it seemed logical to do so. I am glad you are able to replicate the issue.

29

Clients do requests to /nextcloud/ocs/v2.php/apps/... and /nextcloud/remote.php/dav/..., so this might be indeed similar to the /config rewrites in the linked issue, which was fixed only for this particular request.

I can produce the logs when doing requests like:

curl -IL https://my.domain.org/nextcloud/remote.php/dav/
curl -IL https://my.domain.org/nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json
curl -IL https://my.domain.org/nextcloud/ocs/v2.php/apps/user_status/api/v1/user_status?format=json

Getting 401 and 404 (I do not have the user_status app enabled). So any 4xx response seems to lead to a false rewrite. It is not any rule above the #### DO NOT CHANGE ANYTHING ABOVE THIS LINE #### line, as those are not triggered (only apply to requests outside of the Nextcloud dir) and I in fact do not use .htaccess on my personal instance but have those within a dedicated Apache2 config with only those parts relevant with a different base path. The part below that line is also generated by Nextcloud, but dynamically based on the base path.

Requests to core/js/oc.js and core/preview.png do not trigger the errors either, so it must be the last RewriteRule. Strange is that it explicitly excludes /ocs/v(1|2)\.php. Using another excluded path, like robots.txt123, does not trigger the error. Also using /ocs/v2.php does not cause the error, only when further path elements are added. That is true as well for /nextcloud/index.php/123.

30

Okay, actually it is not the rewritten requests which cause the errors, but those which are explicitly excluded by the rewrite, all of them.

I created an empty /var/www/nextcloud/robots.txt.php and while curl -IL https://my.domain.org/nextcloud/robots.txt.php/test returns 200, the log shows client denied by server configuration: /var/www/test. Doing the same with a robots2.txt.php (rewrite does apply), does not cause the error.

https://my.domain.org/test/test.php/abc also triggers the errors when allowing access to /var/www/test.

31

It seems like Nextcloud is completely unrelated to this. We need to test this on a clean Apache2 install:

  • Deny access to /var/www
  • Allow access to /var/www/test
  • Create empty /var/www/test/test.php
  • curl -I 127.0.0.1/test/test.php/test

And if this does not trigger the error, testing the same with PHP-FPM installed, in case an existing backend handler makes a difference, which is very likely, since non-.php files are not affected.

It seems like Apache is internally doing a second request with path elements behind the .php file used as full URL path. Or the other way, round PHP is somehow probing that part at the webserver for some reason.

32

I’m thrilled that you can confirm the issue. Let me know if there is anything I can do to help move this fix forward.

33

Since I’m busy with DietPi v8.15 release now, if you fine time to test a fresh Apache-only setup (at best even with apt install apache2 only, using /var/www/html as webroot), as described above, that would help. We need to rule out any web application and isolate the issue to be Apache2 only, or Apache2 + PHP-FPM, before we can report this at the Debian bug tracker, and from there in case further upstream.

34

I will load up a VM in VirtualBox this afternoon and get this started. Will report back.

1 Like
36

Still testing… I messed up my last install. Trying again.

37

OK, I was unable to confirm the issue, either in Apache alone, or with PHP-FPM installed

Steps:

  • Install Debian Bullsye from clean ISO
  • Install Apache apt install apache2
  • Deny access to /var/www
  • Allow access to /var/www/test
  • Create empty /var/www/test/test.php
  • set virtualhost config root directory to /var/www (was /var/www/html)
  • restart Apache
  • curl -I 127.0.0.1/test/test.php/test
  • access.log 404; error.log no errors

Then:

  • Install PHP-FPM
  • Enable PHP-FPM in Apache and restart Apache
  • curl -I 127.0.0.1/test/test.php/test
  • access.log 200; error.log no errors

It’s probably best someone checks my work just in case.

38

A year and ~9 months later, this is still an issue. I was never able to get to the bottom of it, and resolve it. Perhaps you can have another look @MichaIng when you are back from the holidays?

39

Needs to be reported to either Debian bug tracker or Apache bug tracker. I am busy with the DietPi release currently, will see whether I can do that after Christmas.