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

spiritofjerry · 30 January 2023 00:04

Creating a bug report/issue

Required Information

DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=13
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘applied’
G_LIVE_PATCH_STATUS[1]=‘not applicable’
Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
bullseye
Kernel version | uname -a
Linux DietPi 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Native PC (x86_64)
Power supply used | (EG: 5V 1A RAVpower)
Dell 90w PSU
SD card used | (EG: SanDisk ultra)
PCIe SSD

Additional Information (if applicable)

Software title | (EG: Nextcloud)
Nextcloud
Was the software title installed freshly or updated/migrated?
Fresh install, has been updated several increments
Can this issue be replicated on a fresh installation of DietPi
Have not tried

← If you sent a “dietpi-bugreport”, please paste the ID here →

Bug report ID | echo $G_HW_UUID

Steps to reproduce

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.
journalctl -f -n 75
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

These 403 errors are initiated when opening the Nextloud desktop, web, and Android clients, where Nextcloud is calling on these diretories.

Expected behaviour

No Apache errors for unauthorized directories that also do not exist

…

Actual behaviour

Apache errors for unauthorized directories that also do not exist

…

Extra details

Note that the clients still seem to function OK, with the usual occasional Nextcloud hiccups. Syncing and other things seem to work just fine.

directory paths that are 403’d:
/var/www/apps
/var/www/cloud
/var/www/dav
/var/www/204
/var/www/avatar
etc…

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>

Potentially related issue (but no actual resolution to my specific problem) on Github: https://github.com/nextcloud/server/issues/15688

Joulinar · 30 January 2023 10:00

But these folders are located outside Nextcloud as well as PiHole directories.

spiritofjerry · 30 January 2023 17:19

In my installation, those folders are not in the root web directory. Only apps exists in the Nextcloud directory of those listed, as well.

What I’m saying is that the clients are making calls to directories that do not exist.

Joulinar · 30 January 2023 17:48

But how does DietPi influence your clients and what they do?

spiritofjerry · 30 January 2023 18:13

I have no idea what’s going on. What I do know is that if I change my Apache configs to allow calls to the root directory, those 403s go away. All I know is that Nextcloud keeps making calls to the root directory, and Dietpi is installed at /var/www/Nextcloud. I am wondering if there is some symbolic links logic that is being ignored due to dietpi’s specific apache config.

This could very well be a Nextcloud issue, but I thought I would bring it up here first

Joulinar · 30 January 2023 19:45

we don’t create any of these directories or set any symbolic links like this. Not sure why your client is trying to access them. NC is installed into /var/www/nextcloud. Nothing else is done on /var/www

spiritofjerry · 30 January 2023 21:18

Thanks, that makes sense to me. I will reach out to the Nextcloud community for a better understanding of what’s going on and report back in case others are seeing the issue.

Joulinar · 31 January 2023 09:24

Yes, pls keep us posted.

spiritofjerry · 2 March 2023 08:44

OK, so I created a help ticket on Nextcloud forum, and another user responded yesterday with similar behavior: [authz_core:error] AH01630: client denied by server configuration: /var/www/dav - ℹ️ Support - Nextcloud community

It appears what is happening, and I cannot explain the “why” as I am not an expert in Apache, is that while the actual HTTP requests are going through (i.e. there is no error on the clients, and everything is working), there are identical 403 errors happening due to how the server is configured in Apache default by DietPi.

Some client requests are going to /var/www/apps instead of /var/www/nextcloud/apps – and are subsequently 403’d. There must be some misconfiguration within the Apache server that does not handle these requests properly and route them to the Nextcloud directory.

I can “solve” the errors by uncommenting the following from my Apache config:

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

This allows the 403s to stop filling the error log, but this does not actually stop the requests, which I mention must be a product of the virtual host or directory config in Apache as installed by DietPi. Perhaps why this issue has not come up in the past is because the way DietPi installs Nextcloud is that it is installed as a directory within the base directory, and not as a separate virtualhost (which would be MUCH better for security purposes). As I run Pihole side-by-side with Nextcloud, I need to lock all the directories down, and therefore have modified this bit of the apache config:

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

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

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

This ensures that ONLY the Nextcloud directory is accessible, and not anything else in the document root.

Here is the relevant virtual host config (default) for the server that I have not modified (domain name redacted as “xxxxxxxxxxx”):

000-default.conf

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

Again, it appears it if requests are going to the root directory, which is configured to be /var/www in dietpi.conf:

# /etc/apache2/conf-available/dietpi.conf
# Default server name and webroot
ServerName xxx.xxx.xxx.xxx
DocumentRoot /var/www

So, I do think this is a DietPi issue. The Nextcloud clients are making requests to directories that should exist in /var/www/nextcloud, but the configs and/or rewrite rules on the server don’t allow them to be routed there by default.

I think someone with some better knowledge of how Apache works could solve this issue.

Joulinar · 2 March 2023 10:15

@MichaIng can you have a look pls.

spiritofjerry · 3 March 2023 00:01

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/72736bb04e1e207e1d9068ea30328f11485d4d03/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>

MichaIng · 7 March 2023 20:28

That part breaks vast parts of Nextcloud, which relies on functioning .htaccess also for security relevant blocks to access e.g. the config.php which hold the plain text database credentials, i.e. AllowOverride All is necessary. Directory indexes are however not needed and theoretically imply security risks as well as a 403 (redirect to NC login/main page) would be the alternative. See /etc/apache2/sites-available/dietpi-nextcloud.conf, which conflicts with the above but sets those parts correctly (oh, remove the Content-Security-Policy lines, this wasn’t a good idea and has been removed for fresh installs already).

Since you block access to /var/www, how do you access Pi-hole? Did you move it to a dedicated vhost? To prevent access from WAN, we offer to add an access block from all public IP ranges on install, btw. To enable it afterwards:

a2ensite dietpi-pihole-block_public_admin

Other than that, the false/403 requests look like a client (configuration) issue. I do not see such on my personal instance and two other instances with Apache webserver I know about. Are you sure they are configured to use the /nextcloud path, or are they configured to not use it (causing the 403 attempts), but falling back to trying it?

And I’m missing your HTTPS/443 config to get the full picture.

spiritofjerry · 7 March 2023 21:38

MichaIng:

That part breaks vast parts of Nextcloud

Yes, it would, but as you mention, it’s overwritten in the direct config for Nextcloud. As you may know, this is the default config for that directory (which I commented out, because I’m blocking general access) which must be overwritten regardless:

So everything is working. This is no surprise, you guys made it that way. I went ahead and commented out the duplicate Nextcloud directory stipulation in the base config because it wasn’t necessary.

I have specified those directories my main apache config:

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

And yes, I am using the public directory blocking, which you guys authored, per:

# Block public access to admin panel
<Directory ~ /var/www(/html)?/admin>
        Require ip 127 192.168 10 172.16.0.0/12 ::1/128 fe80::/10 fc00::/7
</Directory>

PiHole works great.

True that, my apologies. Here’s the 443 config (relevant parts). I’m using let’s encrypt, and that’s also working great:

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/html

I do notice that the public document root here conflicts with the public document root for HTTP (/var/www). Is that an issue, or is that by design? Either way, this is how you guys wrote it.

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName xxx.xxx.xxx

Include /etc/letsencrypt/options-ssl-apache.conf
Header always set Strict-Transport-Security "max-age=31536000"
SSLCertificateFile /etc/letsencrypt/live/xxx.xxx.xxx/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxx.xxx.xxx/privkey.pem
</VirtualHost>
</IfModule>

spiritofjerry · 7 March 2023 21:41

Oh, I forgot to mention:

Yes, my clients are all pointing to the /nextcloud directory. They actually have to in order to be able to authenticate with the server and sync. The server URL is required upon sign-in. As I have shown above (and copying here), the clients are making requests to the /nextcloud directory:

e.g.

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"

However, I am still gettting 403s. I do not see any requests from my Windows client to the base directory (/var/www) in the logs. So, I am stumped.

spiritofjerry · 7 March 2023 21:55

I know this probably more helpful for the Nextcloud devs, but I’ll include a bigger snippet of my Nextcloud client logs here just so you can see that my clients, which are hammering my apache with 403s, are indeed serving requests to /nextcloud. This specific log dump is from my Windows client, but the behavior happens across all clients. Perhaps something in here is another clue:

2023-03-07 14:38:50:975 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:1105 ]:	<========== Sync finished for folder [F:\Nextcloud] of account [xxx@xxx.xxx.xxx] with remote [https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/]
2023-03-07 14:39:04:979 [ debug nextcloud.gui.ocsuserstatusconnector C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\ocsuserstatusconnector.cpp:226 ]	[ OCC::OcsUserStatusConnector::fetchUserStatus ]:	Try to fetch user status
2023-03-07 14:39:04:979 [ info nextcloud.sync.accessmanager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\accessmanager.cpp:78 ]:	2 "" "https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/user_status/api/v1/user_status?format=json" has X-Request-ID "3dbed828-8d77-4017-adf8-3f7e9ab0e688"
2023-03-07 14:39:04:979 [ debug nextcloud.sync.cookiejar C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\cookiejar.cpp:90 ]	[ OCC::CookieJar::cookiesForUrl ]:	QUrl("https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/user_status/api/v1/user_status?format=json") requests: (QNetworkCookie("nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc_sessionPassphrase=w%2BbK9et%2FZp2pqAHaGhAUYxkKRPGoLRjN3VlkX3TFcH%2FOpayYT%2Bg9rXut%2BFPKyFv6D%2BmjjWt0C4joa2fq7%2FKRakmdH49JysLWGApd0Qlm6fkIcp3q7PKjZoiEvyz2YU%2FU; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc0scb9mu26o=1eli8v4ft752750k9751clsv4j; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"))
2023-03-07 14:39:04:980 [ info nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:361 ]:	OCC::JsonApiJob created for "https://xxx.xxx.xxx/nextcloud" + "/ocs/v2.php/apps/user_status/api/v1/user_status" "OCC::UserStatusConnector"
2023-03-07 14:39:04:980 [ info nextcloud.sync.accessmanager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\accessmanager.cpp:78 ]:	2 "" "https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json" has X-Request-ID "202c4cc7-47b3-4057-897e-9579558ec07a"
2023-03-07 14:39:04:980 [ debug nextcloud.sync.cookiejar C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\cookiejar.cpp:90 ]	[ OCC::CookieJar::cookiesForUrl ]:	QUrl("https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json") requests: (QNetworkCookie("nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc_sessionPassphrase=w%2BbK9et%2FZp2pqAHaGhAUYxkKRPGoLRjN3VlkX3TFcH%2FOpayYT%2Bg9rXut%2BFPKyFv6D%2BmjjWt0C4joa2fq7%2FKRakmdH49JysLWGApd0Qlm6fkIcp3q7PKjZoiEvyz2YU%2FU; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc0scb9mu26o=1eli8v4ft752750k9751clsv4j; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"))
2023-03-07 14:39:04:980 [ info nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:361 ]:	OCC::JsonApiJob created for "https://xxx.xxx.xxx/nextcloud" + "ocs/v2.php/apps/notifications/api/v2/notifications" "OCC::ServerNotificationHandler"
2023-03-07 14:39:05:011 [ info nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\creds\webflowcredentials.cpp:426 ]:	request finished
2023-03-07 14:39:05:011 [ 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/v2.php/apps/user_status/api/v1/user_status?format=json") FINISHED WITH STATUS "OK"
2023-03-07 14:39:05:012 [ debug nextcloud.gui.ocsuserstatusconnector C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\ocsuserstatusconnector.cpp:312 ]	[ OCC::OcsUserStatusConnector::logResponse ]:	Response from: "user status fetched" Status: 200 Json: QJsonDocument({"ocs":{"data":{"clearAt":null,"icon":null,"message":null,"messageId":null,"messageIsPredefined":false,"status":"offline","statusIsUserDefined":false,"userId":"xxx"},"meta":{"message":"OK","status":"ok","statuscode":200}}})
2023-03-07 14:39:05:012 [ debug nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:298 ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::JsonApiJob finished for "/ocs/v2.php/apps/user_status/api/v1/user_status"
2023-03-07 14:39:05:013 [ info nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\creds\webflowcredentials.cpp:426 ]:	request finished
2023-03-07 14:39:05:013 [ 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/v2.php/apps/notifications/api/v2/notifications?format=json") FINISHED WITH STATUS "OK"
2023-03-07 14:39:05:013 [ warning nextcloud.sync.networkjob.jsonapi C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\networkjobs.cpp:850 ]:	Nothing changed so nothing to retrieve - status code:  304
2023-03-07 14:39:05:013 [ warning nextcloud.gui.servernotification C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\tray\notificationhandler.cpp:73 ]:	Status code  304  Not Modified - No new notifications.
2023-03-07 14:39:05:013 [ debug nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:298 ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::JsonApiJob finished for "ocs/v2.php/apps/notifications/api/v2/notifications"
2023-03-07 14:39:05:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:896 ]:	Etag poll timer timeout
2023-03-07 14:39:05:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:900 ]:	Folders to sync: 1
2023-03-07 14:39:05:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:910 ]:	Number of folders that don't use push notifications: 1
2023-03-07 14:39:05:292 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:927 ]:	Run etag job on folder OCC::Folder(0x1e29faf5a70)
2023-03-07 14:39:05:292 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:951 ]:	Can not run etag job: Polltime not reached
2023-03-07 14:39:35:058 [ info nextcloud.gui.account.state C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\accountstate.cpp:270 ]:	check connectivity
2023-03-07 14:39:35:058 [ debug nextcloud.sync.connectionvalidator C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\connectionvalidator.cpp:175 ]	[ OCC::ConnectionValidator::checkAuthentication ]:	# Check whether authenticated propfind works.
2023-03-07 14:39:35:059 [ info nextcloud.sync.accessmanager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\accessmanager.cpp:78 ]:	6 "PROPFIND" "https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/" has X-Request-ID "c3c13163-c55a-4364-ac4f-7ff1a00c0981"
2023-03-07 14:39:35:059 [ debug nextcloud.sync.cookiejar C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\cookiejar.cpp:90 ]	[ OCC::CookieJar::cookiesForUrl ]:	QUrl("https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/") requests: (QNetworkCookie("nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc_sessionPassphrase=w%2BbK9et%2FZp2pqAHaGhAUYxkKRPGoLRjN3VlkX3TFcH%2FOpayYT%2Bg9rXut%2BFPKyFv6D%2BmjjWt0C4joa2fq7%2FKRakmdH49JysLWGApd0Qlm6fkIcp3q7PKjZoiEvyz2YU%2FU; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc0scb9mu26o=1eli8v4ft752750k9751clsv4j; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"))
2023-03-07 14:39:35:060 [ info nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:361 ]:	OCC::PropfindJob created for "https://xxx.xxx.xxx/nextcloud" + "/" "OCC::ConnectionValidator"
2023-03-07 14:39:35:120 [ info nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\creds\webflowcredentials.cpp:426 ]:	request finished
2023-03-07 14:39:35:120 [ info nextcloud.sync.networkjob.propfind C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\networkjobs.cpp:606 ]:	PROPFIND of QUrl("https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/") FINISHED WITH STATUS "OK"
2023-03-07 14:39:35:120 [ debug nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:298 ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::PropfindJob finished for "/"
2023-03-07 14:39:35:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:896 ]:	Etag poll timer timeout
2023-03-07 14:39:35:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:900 ]:	Folders to sync: 1
2023-03-07 14:39:35:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:910 ]:	Number of folders that don't use push notifications: 1
2023-03-07 14:39:35:291 [ info nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:927 ]:	Run etag job on folder OCC::Folder(0x1e29faf5a70)
2023-03-07 14:39:35:291 [ info nextcloud.gui.folder C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folder.cpp:323 ]:	Trying to check "https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/" for changes via ETag check. (time since last sync: 44 s)
2023-03-07 14:39:35:291 [ debug nextcloud.gui.folder.manager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\folderman.cpp:719 ]	[ OCC::FolderMan::slotRunOneEtagJob ]:	Scheduling "https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/" to check remote ETag
2023-03-07 14:39:35:291 [ info nextcloud.sync.accessmanager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\accessmanager.cpp:78 ]:	6 "PROPFIND" "https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/" has X-Request-ID "9a457b91-ab65-4271-81b8-2c0feaf5d28a"
2023-03-07 14:39:35:291 [ debug nextcloud.sync.cookiejar C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\cookiejar.cpp:90 ]	[ OCC::CookieJar::cookiesForUrl ]:	QUrl("https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/") requests: (QNetworkCookie("nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc_sessionPassphrase=w%2BbK9et%2FZp2pqAHaGhAUYxkKRPGoLRjN3VlkX3TFcH%2FOpayYT%2Bg9rXut%2BFPKyFv6D%2BmjjWt0C4joa2fq7%2FKRakmdH49JysLWGApd0Qlm6fkIcp3q7PKjZoiEvyz2YU%2FU; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc0scb9mu26o=1eli8v4ft752750k9751clsv4j; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"))
2023-03-07 14:39:35:291 [ info nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:361 ]:	OCC::RequestEtagJob created for "https://xxx.xxx.xxx/nextcloud" + "/" "OCC::Folder"
2023-03-07 14:39:35:338 [ info nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\creds\webflowcredentials.cpp:426 ]:	request finished
2023-03-07 14:39:35:338 [ info nextcloud.sync.networkjob.etag C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\networkjobs.cpp:93 ]:	Request Etag of QUrl("https://xxx.xxx.xxx/nextcloud/remote.php/dav/files/xxx/") FINISHED WITH STATUS "OK"
2023-03-07 14:39:35:339 [ debug nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:298 ]	[ OCC::AbstractNetworkJob::slotFinished ]:	Network job OCC::RequestEtagJob finished for "/"
2023-03-07 14:40:04:977 [ debug nextcloud.gui.ocsuserstatusconnector C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\ocsuserstatusconnector.cpp:226 ]	[ OCC::OcsUserStatusConnector::fetchUserStatus ]:	Try to fetch user status
2023-03-07 14:40:04:977 [ info nextcloud.sync.accessmanager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\accessmanager.cpp:78 ]:	2 "" "https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/user_status/api/v1/user_status?format=json" has X-Request-ID "5aa12281-5eb7-4e90-a6b9-b7bfdedfd6a7"
2023-03-07 14:40:04:977 [ debug nextcloud.sync.cookiejar C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\cookiejar.cpp:90 ]	[ OCC::CookieJar::cookiesForUrl ]:	QUrl("https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/user_status/api/v1/user_status?format=json") requests: (QNetworkCookie("nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc_sessionPassphrase=w%2BbK9et%2FZp2pqAHaGhAUYxkKRPGoLRjN3VlkX3TFcH%2FOpayYT%2Bg9rXut%2BFPKyFv6D%2BmjjWt0C4joa2fq7%2FKRakmdH49JysLWGApd0Qlm6fkIcp3q7PKjZoiEvyz2YU%2FU; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc0scb9mu26o=1eli8v4ft752750k9751clsv4j; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"))
2023-03-07 14:40:04:978 [ info nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:361 ]:	OCC::JsonApiJob created for "https://xxx.xxx.xxx/nextcloud" + "/ocs/v2.php/apps/user_status/api/v1/user_status" "OCC::UserStatusConnector"
2023-03-07 14:40:04:978 [ info nextcloud.sync.accessmanager C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\accessmanager.cpp:78 ]:	2 "" "https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json" has X-Request-ID "43fbf1ef-fb21-48c8-861d-264886c911de"
2023-03-07 14:40:04:978 [ debug nextcloud.sync.cookiejar C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\cookiejar.cpp:90 ]	[ OCC::CookieJar::cookiesForUrl ]:	QUrl("https://xxx.xxx.xxx/nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications?format=json") requests: (QNetworkCookie("nc_sameSiteCookielax=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("nc_sameSiteCookiestrict=true; secure; HttpOnly; expires=Fri, 31-Dec-2100 23:59:59 GMT; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc_sessionPassphrase=w%2BbK9et%2FZp2pqAHaGhAUYxkKRPGoLRjN3VlkX3TFcH%2FOpayYT%2Bg9rXut%2BFPKyFv6D%2BmjjWt0C4joa2fq7%2FKRakmdH49JysLWGApd0Qlm6fkIcp3q7PKjZoiEvyz2YU%2FU; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"), QNetworkCookie("oc0scb9mu26o=1eli8v4ft752750k9751clsv4j; secure; HttpOnly; domain=xxx.xxx.xxx; path=/nextcloud"))
2023-03-07 14:40:04:978 [ info nextcloud.sync.networkjob C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\abstractnetworkjob.cpp:361 ]:	OCC::JsonApiJob created for "https://xxx.xxx.xxx/nextcloud" + "ocs/v2.php/apps/notifications/api/v2/notifications" "OCC::ServerNotificationHandler"
2023-03-07 14:40:05:007 [ info nextcloud.sync.credentials.webflow C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\gui\creds\webflowcredentials.cpp:426 ]:	request finished
2023-03-07 14:40:05:007 [ 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/v2.php/apps/user_status/api/v1/user_status?format=json") FINISHED WITH STATUS "OK"
2023-03-07 14:40:05:007 [ debug nextcloud.gui.ocsuserstatusconnector C:\Users\sysadmin\AppData\Local\Temp\2\windows-13476\client-building\desktop\src\libsync\ocsuserstatusconnector.cpp:312 ]	[ OCC::OcsUserStatusConnector::logResponse ]:	Response from: "user status fetched" Status: 200 Json: QJsonDocument({"ocs":{"data":{"clearAt":null,"icon":null,"me

I’ll post this issue to the github repo for Nextcloud so that perhaps this gets more traction there.

MichaIng · 7 March 2023 22:13

The config we use for Pi-hole adds a lot of additional directives, for security and functionality of the Pi-hole web interface.

So you basically block access to /var/www but unblock it again for every directory within, which seems redundant and at least is a potential point of failure depending on which configs are located where (the order in which they are loaded) and the exact kind of directory/location/vhost blocks.

You seem to have two conflicting HTTPS vhost configs. The second looks like the correct one created by Certbot, while I’ve no idea where the first is coming from, it shouldn’t be there, at least not enabled. Please try to disable or remove that one.

Bottom line: You have a lot of custom configs and changes paired with those created by dietpi-software and those created by Certbot. And I do not see the purpose of the custom ones. I’d try remove all customisations and go with a clean dietpi-software + dietpi-letsencrypt setup, or otherwise with a custom setup, not using our tools. Going the first route, you can still re-add customisations, but do it one by one in small steps, so you better know which part is causing the faulty client accesses.

If you face any issue with the clean dietpi-software + dietpi-letsencrypt setup, or have any particular reason for your customisations, please let us know, so we can enhance.

spiritofjerry · 7 March 2023 22:29

No, I specifically allow access to the existing directories, and block access to everything that does not exist. The directories that exist still have the same configurations as was set to /var/www, and everything works as intended. This isn’t redundant, it’s to prevent prying eyes from access to my server and allows me to see bot attempts to access forbidden directories on the server, which I can then block.

and at least is a potential point of failure depending on which configs are located where (the order in which they are loaded) and the exact kind of directory/location/vhost blocks.

Again, everything is working perfectly, and specific configs (which you authored, not me) are overwriting where needed. The ONLY thing I changed was blocking general access to my apache server outside of defined directories.

One is the default, the other is the Let’s Encrypt. The Let’s Encrypt vhost was created by a script you wrote, and overwrites the default. Should users of your operating system know to delete default configs after running your software installs? I figured you would write scripts that would properly overwrite default configs, but perhaps that was faulty thinking. I will try commenting out the default SSL config, which came installed and I did not touch.

Bottom line: You have a lot of custom configs and changes paired with those created by dietpi-software and those created by Certbot.

No, I made ONE configuration change: I blocked general access to /var/www and opened the specific directories with the exact same directives applied to /var/www. That’s it. That’s all I’ve authored. The rest was done by software install scripts you authored.

spiritofjerry · 7 March 2023 23:35

I have created a bug report here: [Bug]: [authz_core:error] AH01630: client denied by server configuration: /var/www/apps (dav/cloud/etc) · Issue #37115 · nextcloud/server · GitHub

I will report back on any traction that it gets.

MichaIng · 11 March 2023 15:11

That is exactly what I mean with “redundant”. Why do you block access to something which does not exist anyway? Could be seen as a security measure, but since you obviously have issues with your setup, at least try to undo this change.

Still not as you expect as you opened a bug report at Nextcloud. Note that this is not a Nextcloud issue but an issue with your Apache setup, so that bug report is misplaced.

How do you know that it is not the other way round, which config overwrites which/has higher priority? And again, that default config shipped with the Apache package is a template which is not used and not enabled by default, even actively disabled by Certbot, reasonably, since it doubles/conflicts with the Certbot config.

And you enabled the default SSL config. Again, everything works fine without any custom changes, but with your multiple redundant configs if does not all work as expected. So before opening bug reports please do test the untouched default config and apply your modifications one by one to find out which one breaks the expectations.

spiritofjerry · 11 March 2023 17:38

No, it’s not redundant, it’s a sensible security measure that I told you about in the comment prior. 403 logs allow me to fail2ban bots and bad actors searching for directories on my server that do not exist.

Still not as you expect as you opened a bug report at Nextcloud.

True, but the core application works without issue.

Note that this is not a Nextcloud issue but an issue with your Apache setup, so that bug report is misplaced.

Mind you, I came here, first, as this issue is not caused by me. It is either an issue that is inherent in the setup based on your install scripts, or it is in fact an issue caused by Nextloud’s inherent structure. I did not author any specific rewrite rules that should be causing this to happen. I made a sensible change to the base Apache config.

How do you know that it is not the other way round, which config overwrites which/has higher priority?

I would hope that you would know your own software

And again, that default config shipped with the Apache package is a template which is not used and not enabled by default, even actively disabled by Certbot, reasonably, since it doubles/conflicts with the Certbot config.

The default config and Certbot config files are exactly as-is, and I have not touched anything, so your software is responsible for whatever is enabled/disabled.

And you enabled the default SSL config.

Nope. Your software did. I did not touch anything related to SSL, I only used your supplied scripts. BTW, disabling the default SSL config did not solve the issue, so I have no idea what you’re going on about how I broke things.