-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: WebDAV interface seems to be broken #39549
Comments
Hi @lim0nad3 - Try adding You may also want to double check your nginx config is up-to-date. The suggested one changed a little bit during the NC26 period so if you have updated it lately it may not reflect current needs: |
Hi @joshtrichards, thank you for reply.
However, it brought no change. Following the upgrade to version 27 and the appearance of the error message, the first thing I did was to check the nginx configuration with the documentation. This is my site conf: upstream php-handler {
server unix:/var/run/php/php8.2-fpm.sock;
}
# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
"" "";
default "immutable";
}
# logging
access_log /var/log/nginx/***FQDN***_access.log;
error_log /var/log/nginx/***FQDN***_error.log;
server {
listen 80;
listen [::]:80;
server_name ***FQDN***;
# Prevent nginx HTTP Server Detection
server_tokens off;
# For Lets Encrypt
location /.well-known/acme-challenge/ {
root /var/www/***FQDN***/public_html/;
}
location /.well-known/pki-validation/ {
root /var/www/***FQDN***/public_html/;
}
# Enforce HTTPS just for `/nextcloud`
location /nextcloud {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name ***FQDN*** ;
# Path to the root of the domain
root /var/www/***FQDN***/public_html/;
# ssl on;
# Use Mozilla's guidelines for SSL/TLS settings
# https://mozilla.github.io/server-side-tls/ssl-config-generator/
ssl_certificate /etc/nginx/ssl/***FQDN***.crt;
ssl_certificate_key /etc/nginx/ssl/***FQDN***.key;
# Prevent nginx HTTP Server Detection
server_tokens off;
# HSTS settings
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" always;
# Add .mjs as a file extension for javascript
# Either include it in the default mime.types list
# or include you can include that list explicitly and add the file extension
# only for Nextcloud like below:
include mime.types;
types {
text/javascript js mjs;
}
location = /robots.txt {
add_header Content-Type text/plain;
return 200 "User-agent: *\nDisallow: /\n";
}
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in the Nextcloud `.htaccess` that concern `/.well-known`.
location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
location = /.well-known/caldav { return 301 /nextcloud/remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /nextcloud/index.php$request_uri;
}
location ^~ /nextcloud {
# set max upload size and increase upload timeout:
client_max_body_size 512M;
client_body_timeout 300s;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Pagespeed is not supported by Nextcloud, so if your server is built
# with the `ngx_pagespeed` module, uncomment this line to disable it.
#pagespeed off;
# The settings allows you to optimize the HTTP2 bandwitdth.
# See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
# for tunning hints
client_body_buffer_size 512k;
# HTTP response headers borrowed from Nextcloud `.htaccess`
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "noindex, nofollow" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Specify how to handle directories -- specifying `/nextcloud/index.php$request_uri`
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
# `try_files $uri $uri/ /nextcloud/index.php$request_uri`
# always provides the desired behaviour.
index index.php index.html /nextcloud/index.php$request_uri;
# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = /nextcloud {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /nextcloud/remote.php/webdav/$is_args$args;
}
}
# Rules borrowed from `.htaccess` to hide certain paths from clients
location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends
# `/nextcloud/index.php` to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
# Required for legacy support
rewrite ^/nextcloud/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /nextcloud/index.php$request_uri;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_max_temp_file_size 0;
}
location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
try_files $uri /nextcloud/index.php$request_uri;
add_header Cache-Control "public, max-age=15778463, $asset_immutable";
access_log off; # Optional: Don't log access to assets
location ~ \.wasm$ {
default_type application/wasm;
}
}
location ~ \.woff2?$ {
try_files $uri /nextcloud/index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
}
# Rule borrowed from `.htaccess`
location /nextcloud/remote {
return 301 /nextcloud/remote.php$request_uri;
}
location /nextcloud {
try_files $uri $uri/ /nextcloud/index.php$request_uri;
}
}
} I tried to comment/remove this section but the behaviour was the same: # For Lets Encrypt
location /.well-known/acme-challenge/ {
root /var/www/***FQDN***/public_html/;
}
location /.well-known/pki-validation/ {
root /var/www/***FQDN***/public_html/;
} This is my nginx conf: user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
#ssl_ciphers HIGH; # Fallback for compatibility
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
ssl_ecdh_curve secp384r1;
# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000" always;
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Headers Settings
##
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
} Do you have any other suggestions regarding the issue? |
Freaking hell - it got me, ran into the same issue. I always thought upgrading to a major .0.1 release would be safe! Not this time:
⚠⚠⚠ What to do/test/try next? Nextcloud (a productive instance!) is completely OUT OF ORDER because of this ⚠⚠⚠ I'm running nginx and carefully took a look at the nginx example config, even compared https://docs.nextcloud.com/server/26/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx with https://docs.nextcloud.com/server/27/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx and only found two little changes, which are for sure not related to this massive WebDAV is completely dead issue:
Edit/Update:After looking at the NC log again... So I checked https://my-server.local/settings/apps/installed/files_locking where the app was shown pretty strange (version: ➡ After disabling the app ( As Probable not many instances still have this app installed - which could be the reason for not that many running into this "an app broke the complete NC instance" situation. At least looking at https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html at the |
Thank you for sharing your experience @bcutter.
I have raised the logging level to debug and I am encountering the following error:
|
Okay, so same outcome (no WebDAV service) but obviously different root causes. I was hoping my "files_locking" discovery would help others and fix your issue too. |
@lim0nad3 What is the first line of output when you execute this from the command-line:
The check that generates Lines 23 to 33 in 5d9b84d
Also, take a look at your browser console, open the Network tab, then trigger a re-run of the checks. See what the request for |
@bcutter Yeah I think the cause of your situation was unrelated to this Issue's topic. I've only heard of the |
Hi @joshtrichards, I'm sorry for the delay in replying, I returned today from vacation. The curl request response is actually 401: HTTP/2 401
server: nginx
date: Sat, 02 Sep 2023 08:12:50 GMT
content-type: application/xml; charset=utf-8
set-cookie: oc_sessionPassphrase=***REMOVED SENSITIVE VALUE***; path=/nextcloud; secure; HttpOnly; SameSite=Lax
set-cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
set-cookie: ***REMOVED SENSITIVE VALUE***; path=/nextcloud; secure; HttpOnly; SameSite=Lax
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
content-security-policy: default-src 'none';
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN From browser, after authenticating (without being prompted for OTP passcode), I get error Internal server error, in console I get error code "Status 401 Unauthorized". What I don't understand is that client synchronization should not work if this is true, am I wrong? In my case everything works correctly. Nextcloud client, web interface and webdav synchronization with DAVx on Android. I point out that I upgraded to version 27.0.2 but the situation is the same. 202030918 - UPDATE: same behaviour with 27.1.0.7 version. |
Hello @joshtrichards, after manual upgrade to 27.1.1.0 version I retried curl command you suggested. <?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:o="http://owncloud.org/ns">
<s:exception>OCA\DAV\Connector\Sabre\Exception\PasswordLoginForbidden</s:exception>
<s:message/>
<o:hint xmlns:o="o:">password login forbidden</o:hint>
</d:error> From the browser I receive the following message:
Anyway, in the overview of the administrative interface, in the setup & warnings section, I keep getting the error:
Do you have any other suggestions? |
New user here, and I have the exact same issue @lim0nad3. I can't find a solution anywhere. I installed NextCloud 27.1.1 using the web installer (setup-nextcloud.php). Everything went smoothly. When I try to access /.well-known/caldav it redirects me to remote.php/dav/ and prints
I believe that is the intended scenario. Yet, I also have the
Strangely enough, this is what I see in the dev console of Chrome :
|
Hello @Mysterius , I was starting to feel lonely 🙂 |
There are some infos that I may not have, being on a shared hosting. However, the machine is running CloudLinux 1.3 and i'm using php 8.2 with MySQL. |
Same issue with 27.1.2.1 |
After updating to version 27.1.2, I faced the same problem. In the Nextcloud logs there were many errors concerning the app "Group Folders", e.g.:
So I deactivated this app and indeed: the error message on the admin page disappeared and I had access to my files again. I then uninstalled the "Group Folders" app and reloaded it from the Appstore (version 15.3.1). Immediately after activating the app, the problem occurred again, so I definitely assume some connection with the app. Unfortunately, I do not have the time to dive deeper at the moment, but I would like to briefly share my observation with you. Just check if you have the group folder app installed and try to disable it ( |
Hello @lsr-dev, unfortunately I don't have the Group Folder application installed. |
Yes, I also noticed later that the Group Folders app does not show up in your list, @lim0nad3. Apparently the problem is more general after all. Perhaps my observations will be helpful to someone anyway. Good luck to you! |
I was receiving errors about misconfigurations for caldav and carddav on the overview page on the new installation for client. I was running mariadb, nginx and php 8.2.11 with Nextcloud 27.1.2 on Almalinux 9.
I noticed that on different installation that I was not getting this error even after upgrading it from Nextcloud 26 to 27.1.2. After some investigating I noticed that it was running php 8.1.22 instead of 8.2.11. I tried switching to 8.1.24 on the new installation and the errors went away and then after switching back to 8.2.11 they came back. |
Dear @darkdecoy , thank you for your sharings. Thank you again, you solved my issue 🙂 |
Interesting that you did not get any errors with php 8.1.24, @darkdecoy. Are you using the Group Folder app? As described above, I do not have access to my files when I enable the app, probably due to some unknown method. In the Files app, the following message appears:
The administration page shows: Lastly, entering the "personal settings" menu results in an internal server error. All this only since the upgrade to 27.1.2. And all this can be fixed in my case by disabling the Group Folders app. Since I do not really need the app, it is an acceptable workaround for me. But on occasion I will check if a PHP update permanently solves the problem. |
We aren't not using the guest folder app but we do have the group folders app installed and enabled with no errors. |
Sorry, I got it mixed up (there is also a Guest App for Nextcloud and Owncloud). But of course I meant the Group Folders app. Exciting that it works for you without any problems.... |
I seem to have the same issue (nextcloud/groupfolders#2618). edit: problem solved. PHP 8.2 was not properly configured. |
@lim0nad3 & @Mysterius - Please try from a different browser, a private/incognito browser window, and with brower extensions (such as ublock, ad blockers, etc.) disabled. Though I suspect to two of you have entirely different underlying causes. @lim0nad3 The curl test is probably failing if you're using totp. Try it with your app password (or create a dedicated one for the test). |
I use the docker image of nextcloud and I too have broken webdav interface now. I cannot download whole folders with wget anymore. I have never had group folders app installed or enabled. I do not have totp enabled and tried the download with app password as well - what would be the correct headers to pass to wget in this case? Just http authentication with user and the app password? |
Check if you have PHP 8.2 properly installed and setup. That's what caused my problem. |
Hello @joshtrichards, |
I can't comment on the problem anymore, though what I can say is that I installed using the web installer when I had that problem. |
I also have the problem, but it only occurs sporadically, sometimes after 16 hours, sometimes after 6 hours. I use the nextcloud:fpm image (27.1.4) with an Nginx (installed on the host) the fpm image uses PHP 8.2.13. I also use the Nextcloud Windows and Android app. When I log in to Nextcloud I see the message: Your web server is not yet properly set up to allow file synchronization, because the WebDAV interface seems to be broken. I don't see any errors in the logs. 2 options fix the problem temporarily:
I use the following apps:
|
Update: Today, after 24 hours, my nextcloud instance is not accessible again.
After restarting the container, WebDAV works again |
Closing as the original reporter's matter has been addressed: #39549 (comment) For the rest of you, keep in mind that this message is a general error and there can be multiple underlying causes. Not every person experiencing this is getting the warning for the same reason. So for those of you that end up here or those on this thread that are still experiencing this, you will need to diagnose your situations with that in mind. I would suggest by starting at the community help forum - https://help.nextcloud.com - and sharing as much information as you can (there not here) about your installation/environment to assist with the troubleshooting process. |
Bug description
After upgrading to 27.0.1 from 26.0.4 I receive this error in Administration settings page:
Your web server is not yet properly set up to allow file synchronization, because the WebDAV interface seems to be broken.
The functionality of the mobile and desktop client, as well as sync caldav from android does not seem to be impacted. I can sync the calendar correctly and upload files.
Steps to reproduce
Expected behavior
Correct server configuration info message.
Installation method
Community Manual installation with Archive
Nextcloud Server version
27
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
I searched for the indicated error on the internet and community but found nothing useful.
The text was updated successfully, but these errors were encountered: