[authz_core:error] AH01630: client denied by server configuration: /var/www/dav

Nextcloud version (eg, 20.0.5): Nextcloud Hub 3 (25.0.3)
Operating system and version (eg, Ubuntu 20.04): DietPi Debian bullseye
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.54
PHP version (eg, 7.4): 7.4.33

The issue you are facing:
I am getting multiple 403s from Nextcloud clients (web, Android, PC) with the following error log output (where x.x.x.x below is my local IP address):

Feb 01 18:59:12 DietPi apache2[222383]: [authz_core:error] [pid 222383:tid 140497691596544] [client x.x.x.x:49561] AH01630: client denied by server configuration: /var/www/dav
Feb 01 18:59:27 DietPi apache2[222383]: [authz_core:error] [pid 222383:tid 140498597549824] [client x.x.x.x:49816] AH01630: client denied by server configuration: /var/www/apps
Feb 01 18:59:32 DietPi apache2[222383]: [authz_core:error] [pid 222383:tid 140498605942528] [client x.x.x.x:49861] AH01630: client denied by server configuration: /var/www/apps
Feb 01 18:59:32 DietPi apache2[222383]: [authz_core:error] [pid 222383:tid 140497381197568] [client x.x.x.x:49860] AH01630: client denied by server configuration: /var/www/apps
Feb 01 18:59:38 DietPi apache2[222383]: [authz_core:error] [pid 222383:tid 140497532200704] [client x.x.x.x:49903] AH01630: client denied by server configuration: /var/www/dav

It appears the clients are routing requests for the following (nonexistent) directories:

/var/www/apps
/var/www/cloud
/var/www/dav
/var/www/204
/var/www/avatar

These directories do not exist outside of the /var/www/nextcloud directory, and only /apps exists within the /var/www/nextcloud directory, so I have no idea why these requests are being made by both my Android and PC clients.

I have written a detailed account of the error at the DietPi forum: https://dietpi.com/forum/t/nextcloud-authz-core-error-ah01630-client-denied-by-server-configuration-var-www-apps-dav-cloud-etc/15778

Is this the first time you’ve seen this error? (Y/N):
Yes. I noticed the 403s when viewing dietpi system logs from Apache.

Steps to replicate it:

  1. Restrict general root directory access (require all denied) in Apache config, opening (require all granted) only directories with running services. I have Nextcloud and PiHole configured on this server, both are served from different directories.
  2. journalctl -f -n 75
  3. See tons of 403 errors where my internal IPs are getting denied from certain Nextcloud directories that do not exist. E.G. [authz_core:error] [pid 222383:tid 140497423161088] [client X.X.X.X:55662] AH01630: client denied by server configuration: /var/www/dav

Output of my main Apache config:

<Directory />
        Options FollowSymLinks
        AllowOverride None
        Require all denied
</Directory>

<Directory /usr/share>
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/nextcloud>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/admin>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/html/admin>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

The output of your Nextcloud log in Admin > Logging:

Nothing relevant, see screengrab

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'passwordsalt' => 'xxxxx',
  'secret' => 'xxxxx',
  'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '*',
  ),
  'datadirectory' => '/mnt/xxxxx/nextcloud_data',
  'dbtype' => 'mysql',
  'version' => '25.0.3.2',
  'hashingThreads' => 4,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'filelocking.enabled' => true,
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '/run/redis/redis-server.sock',
    'port' => 0,
  ),
  'overwrite.cli.url' => 'https://xxxx.xxx/nextcloud',
  'htaccess.RewriteBase' => '/nextcloud',
  'dbname' => 'xxxxxx',
  'dbhost' => 'xxxxxx',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'xxxxx',
  'dbpassword' => 'xxxxxx',
  'installed' => true,
  'instanceid' => 'xxxxx',
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' =>
  array (
  ),
  'twofactor_enforced_excluded_groups' =>
  array (
  ),
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'mail_smtphost' => 'xxx.xxx.xxx',
  'mail_smtpport' => '587',
  'mail_from_address' => 'xxxxxx',
  'mail_domain' => 'xxxx.com',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtpname' => 'xxxxx@xxx.com',
  'mail_smtppassword' => 'xxxxxx',
  'mail_smtpsecure' => 'tls',
  'default_phone_region' => 'US',
  'memories.exiftool' => '/var/www/nextcloud/apps/memories/exiftool-bin/exiftool-amd64-glibc',
  'memories.ffmpeg_path' => '/usr/bin/ffmpeg',
  'memories.ffprobe_path' => '/usr/bin/ffprobe',
  'memories.transcoder' => '/var/www/nextcloud/apps/memories/exiftool-bin/go-vod-amd64',
  'memories.no_transcode' => true,
  'memories.qsv' => true,
);

The output of your Apache/nginx/system log in /var/log/____:
See above.

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

See screengrab above. Nothing relevant.

Not a single reply. Is this the norm for this community?

I’ll keep this thread and the lack of help herein in mind when people ask me about Nextcloud and whether they should pursue it as a solution.

HI @spiritofjerry ,

I’m facing exactly the same situation as you. Get tons of 403 errors in apache2 logs like

[Wed Mar 01 12:17:00.178934 2023] [authz_core:error] [pid 34494:tid 140335548188416] [client xxx.xxx.xxx.xxx:60726] AH01630: client denied by server configuration: /aplica/nextcloud/www/apps

This directory not exists as nextcloud is installed in a subfolder ‘/aplica/nextcloud/www/nextcloud/’ so the request should go to ’ ‘/aplica/nextcloud/www/nextcloud/apps’

Also having request to /dav

But the weirdest thing is that Nextcloud seems to work fine! No errors seen on the client side! When I use tail -f to check both access & error logs for apache I observe that each 403 is triggered for successful request for example “Notification”:

[in access.log]
xxx.xxx.xxx.xxx - - [01/Mar/2023:12:22:31 +0100] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications HTTP/2.0" 304 714 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36"
...
[in error.log]
[Wed Mar 01 12:22:31.947637 2023] [authz_core:error] [pid 35020:tid 140294595712768] [client xxx.xxx.xxx.xxx:54739] AH01630: client denied by server configuration: /aplica/nextcloud/www/apps

As you may see, request is done to the proper URL, and response is a 200 code, BUT I got a parallel message on error claiming about trying to access to a non-existent path.

I’m wondering if some Rewrite rule could be the responsible of this mess, but haven’t found any clue

This is my sites-enabled conf file

<IfModule mod_ssl.c>
	<VirtualHost _default_:443>
		DocumentRoot /aplica/nextcloud/www
		RewriteEngine on
		RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
		RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
		RewriteRule ^/\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
		RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]

Alias /nextcloud "/aplica/nextcloud/www/nextcloud/"

<Directory /aplica/nextcloud/www/nextcloud>
  Require all granted
  AllowOverride All
  Options FollowSymLinks MultiViews
   ...
</Directory>

After loooooong research on the internet and dozens of probes I’ve found a “solution” here Apache2: 'AH01630: client denied by server configuration' - Stack Overflow . I quote because I don’t fully understand how this “fix” the problem, but anyway I get ride off the error messages flood.

Seems that the problem could be related to php8.1-fpm

Add this to your vhost conf:

<Location />
require all granted
</Location>

If anyone can add more light to this or help me to tune this solution, I’ll be great.

Hello Gonzalo,

Adding the “require all” rule will indeed stop the errors, but that solution doesn’t work for me as I have some directories within the parent directory (/var/www) that should not be accessible. This solution does not address the problem, which is that there are requests being sent to directories that do not exist within the parent directory OR the Nextcloud directory.

I do think you’re onto something that the rewrite rules are potentially to blame for the actual errors, but I still don’t understand why I’m getting requests to directories that do not exist anywhere.

Here are my relevant config files:

000-default.conf

<VirtualHost *:80>
        ServerName xxxxxxxxxx
RewriteEngine on
RewriteCond %{SERVER_NAME} =xxxxxxxxxx
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

dietpi-nextcloud.conf

# Location: /etc/apache2/sites-available/dietpi-nextcloud.conf
# Based on: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/source_installation.rst#ap>

# Redirect webfinger and nodeinfo requests to Nextcloud endpoint
Redirect 301 /.well-known/webfinger /nextcloud/index.php/.well-known/webfinger
Redirect 301 /.well-known/nodeinfo  /nextcloud/index.php/.well-known/nodeinfo

<Directory /var/www/nextcloud>
        Require all granted
        AllowOverride All
        Options FollowSymLinks

        <IfModule mod_dav.c>
                Dav off
        </IfModule>

        # https://github.com/MichaIng/DietPi/issues/3694
        Header unset Content-Security-Policy
        Header always unset Content-Security-Policy
</Directory>```

To me, it seems like the issue is that specifying a different document root other than the Nextcloud directory is causing this behavior. I am not sure how to remedy as DietPi installs Nextcloud as a directory within the main document root rather than as a virtual host.

Finally we decided to move nextcloud vhost from a directory to the root folder, as we don’t have any specific reason to keep under a “/nextcloud/”.

Error messages have now disappeared.

OK, digging a bit deeper, the clients are indeed querying the correct URLs as I’ve taken a log dump of the Windows client.

2023-03-02 16:22:12:422 [ info nextcloud.sync.networkjob.jsonapi C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\networkjobs.cpp:829 ]:	JsonApiJob of QUrl("https://xxx.xxx.xxx/nextcloud/ocs/v1.php/cloud/user?format=json") FINISHED WITH STATUS "OK"

There are parallel 403s that align with these requests. In the case of the above, it looks like this:

Mar 02 16:21:46 DietPi apache2[1947977]: [authz_core:error] [pid 1947977:tid 140460974655232] [client 192.168.1.4:53370] AH01630: client denied by server configuration: /var/www/cloud

It appears something is happening with the request rewrite that’s allowing the actual request to go through (200 OK), but also triggering a 403. Let’s gather all the rewrite configs that I can find.

Here’s the default config file for the virtual host:

000-default.conf

<VirtualHost *:80>
        ServerName xxx.xxx.xxx
RewriteEngine on
RewriteCond %{SERVER_NAME} =xxx.xxx.xxx
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Here’s the relevant portion of the .htaccess file located in the /var/www/nextcloud directory:

<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>

Here’s a config from /etc/apache/conf-enabled:

dietpi-dav_redirect.conf

# Redirect Cal/CardDAV requests to Nextcloud endpoint:
Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav  /nextcloud/remote.php/dav

Here’s a config from /etc/apache2/sites-enabled:

dietpi-nextcloud.conf

# Location: /etc/apache2/sites-available/dietpi-nextcloud.conf
# Based on: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/source_installation.rst#apache-web-server-configuration

# Redirect webfinger and nodeinfo requests to Nextcloud endpoint
Redirect 301 /.well-known/webfinger /nextcloud/index.php/.well-known/webfinger
Redirect 301 /.well-known/nodeinfo  /nextcloud/index.php/.well-known/nodeinfo

<Directory /var/www/nextcloud>
        Require all granted
        AllowOverride All
        Options FollowSymLinks

        <IfModule mod_dav.c>
                Dav off
        </IfModule>

        # https://github.com/MichaIng/DietPi/issues/3694
        Header unset Content-Security-Policy
        Header always unset Content-Security-Policy
</Directory>

In my case, this problem was caused by the DocumentRoot and Alias directives in the Apache config. From your example:

DocumentRoot /aplica/nextcloud/www
...
Alias /nextcloud "/aplica/nextcloud/www/nextcloud/"

Removing the DocumentRoot line solved the problem for me. Depending on the setup, it may be better to remove the Alias line instead.

In the official docs they use one or the other: Installation on Linux — Nextcloud latest Administration Manual latest documentation