@martijnk
rclone is not a nextcloud but a linux tool and therefore you must search for the solution on linux and not on nextcloud.
it is normal that user can see a lot of data of other user.
The rights normally set to 644 (rwxr–r–) for files and 755 (rwxr-xr-x) for directorys.
You can deny “all” with setting to 640 and 750 . man chmod
With wrong rights you can destroy your nextcloud and/or linux installation.
Read manuals for setting the correct rights for files and directorys.
The problem is that your webserver is owner of all files and has set them for read for all users.
Normal user does not have an linux account on nextcloud servers and they use e.g. WebDAV and not rclone with shell access.
I understand but rclone uses webdav. There are more files/directories in the nextcloud data directory that I can’t see with rclone but I can see all username folders.
I do have this in NGINX (copied from the nextcloud docs):
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The following 6 rules are borrowed from `.htaccess`
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
}
I will try with the Nextcloud client and see what will happen.
I had another look at the documentation and noticed one thing that is different, but I’m not sure if this is causing it.
You have something extra in your config, which is not part of the documentation:
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
Can you replace this with the following (please make sure to create a copy of the config first)
# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;
Yeah they must have updated it since I last copy/pasted it. I get the same behavior though changing those lines. I even fully copy/pasted that config again but same result.