[Bug]: [authz_core:error] AH01630: client denied by server configuration: /var/www/apps (dav/cloud/etc) #37115
Comments
wpwentzell
added
0. Needs triage
|
Doing a bit more digging, this bug report seems related to my issue: #15688 It appears as though the requests are indeed making it through, but something is triggering a 403 regardless. |
|
https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#logging is a good start to debug mod rewrite rules. |
|
Same issue on ubuntu 22.04, apache 2.4.57, php fpm 8.2.10 with minimal configuration of document root directory (access is denied at a higher level) : apache reports many 403 when using app or browsing directly to https://domain.tld/dav : changing to: now browsing to https://domain.tld/dav is allowed (reports 404 of course), but 403 from app continue to flow. change again: no 403 anymore. I guess it's not http request (client) but a file system issue, probably server side php code. hope this helps to debug. |
Bug description
Let me start by saying that I am not sure if this issue is more applicable to the server or desktop client repositories, so I am starting here.
When I restrict root directory access (/var/www; require all denied) within and Apache and subsequently open the Nextcloud directory access (/var/www/nextcloud; require all granted) with the same directives as applied to the root directory, I get tons of 403 errors to my install. These 403 errors are all coming from my many clients and the web interface. What makes this harder to troubleshoot is that everything actually works as expected: clients all sync properly, and can access the server. I can access the server from the web interface without issue. The server logs are clean and do not show any errors related to this behavior. Client logs all show correct routing requests to the /nextcloud directory.
I have made extensive issue reports about this behavior in the Nextcloud community and in the DietPi (OS) community without resolution.
directory paths that are 403’d:
/var/www/apps
/var/www/cloud
/var/www/dav
/var/www/204
/var/www/avatar
etc…
Many of these directories that are 403'd do not actually even exist, even in /var/www/nextcloud. The vast majority of the 403'd directories are /dav, /cloud, and /apps
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/cloudSteps to reproduce
Expected behavior
No 403 errors should appear for clients accessing the Nextcloud server
Installation method
Other Community project
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated to a major version (ex. 22.2.3 to 23.0.1)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "localhost", "*" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "25.0.4.1", "hashingThreads": 4, "memcache.local": "\\OC\\Memcache\\APCu", "filelocking.enabled": true, "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 0 }, "overwrite.cli.url": "https:\/\/sauce.hopto.org\/nextcloud", "htaccess.RewriteBase": "\/nextcloud", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "twofactor_enforced": "true", "twofactor_enforced_groups": [], "twofactor_enforced_excluded_groups": [], "mail_smtpmode": "smtp", "mail_sendmailmode": "smtp", "maintenance": false, "theme": "", "loglevel": 2, "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "587", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtpauthtype": "LOGIN", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "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 } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Using DietPi OS for automated install for Nextcloud. I have raised this issue with them first: https://dietpi.com/forum/t/nextcloud-authz-core-error-ah01630-client-denied-by-server-configuration-var-www-apps-dav-cloud-etc/15778/11
The text was updated successfully, but these errors were encountered: