Via webdav(s) filesystem entries from different users cannot be distinguished

Say, some other user shares his “Photos” folder with you. Then you see this one in your toplevel directory as “Photos (2)”, assumed, you also have a toplevel folder “Photos”.
In the owner’s column of nextcloud’s web UI you can see, that this folder is belonging to someone else. But via webdav this is not easily visible.
As it is, imo it is hard to distinguish, what data this actually is, where i’m moving around. I’d prefer other’s data to be located e.g. in a dedicated toplevel folder for each other user e.g. called “@”, both in the web ui and via webdav(s), so i’d like to issue this as a feature request.
When i find the time, i’ll look into it, how to implement, but it seems quite a notable modification to me.

Thank you. With best regards,

I also do not really like it.

But you can create a folder e.g. “federation”, “user” or “user xyz” and move all the folders in this folder. But i think it is not possible to rename the shared folder.

Also federation with a different server is mostly slow or does not work. I only use it to copy files from one Nextcloud to another. Saves the way over a local download. But i do not work online with a second Nextcloud through federation.

Now this can’t be true !
I did exactly this: created a folder and moved the one shared from another user into this folder and now i do not see any files or directories anymore via webdav. The file manager (dolphin) says: No files
They are still in place, when i check via the Web UI, but the webdav access is broken.
I tried to revert the change via the nextcloud web UI, but nothing helps.
Help ! i want my webdav access back !

!?! Now it works again and as expected. Had the “Too many requests” phenomenon in the meantime and purged the oc_bruteforce_attempts table after checking.
Why can there be too many requests ? There was no wrong password used. Anyway.

You can deactivate bruteforce in config/config.php
‘’ => false,

Do you use a reverse proxy? I think bruteforce makes less sense.


'trusted_proxies' => '172.18.0.x/16',
  '' => false,

Thank you very much for the hints. Yes, i use a reverse proxy.
However i wonder, why those many entries in the table were made. I saw there dozens of lines containing only valid credentials. Why is this considered kind of an attack ?
And i don’t consider it state of art to write credentials - whatever they are used for - in plaintext wherever, especially when they are valid.

If you run Nextcloud behind a reverse proxy Nextcloud see the ip address of your reverse proxy as ip addresse. Hence not your ip address is blocked but the ip of the reverse proxy. You need some additional configuration to make it work.

And i don’t consider it state of art to write credentials - whatever they are used for - in plaintext wherever, especially when they are valid.

Where do you see the credentials? In nextcloud.log?

I know, that nc requires certain configuration, when behind a reverse proxy, and this is set up. This is not the problem. I’ve been running nextcloud this way from the start and it works since many months. It was just a phase of a few hours, when i got the “Too many requests”. No idea, why. Nothing had changed with the setup or configuration or on any client side (browsers, nextcloud android app, dolphin file manager).
I encountered the credentials in the table oc_bruteforce_attempts , before i removed all the entries to get rid of the “Too many requests” error.

Maybe you can increase loglevel in config/config.php. Maybe you find some hints e.g. to much useless communications. Also you can use tools e.g. lsof.