The Basics
- Nextcloud Server version (e.g., 29.x.x):
29.0.13
- Operating system and version (e.g., Ubuntu 24.04):
Debian GNU/Linux 12
- Web server and version (e.g, Apache 2.4.25):
nginx/1.22.1
- Reverse proxy and version _(e.g. nginx 1.27.2)
nginx/1.22.1
- PHP version (e.g, 8.3):
php8.3-fpm
- Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
Download, extract, ...
- Are you using CloudfIare, mod_security, or similar? (Yes / No)
no
Summary of the issue you are facing:
We used to operate a nextcloud instance on which all users had all-encompassing rights within the folders made accessible to them. Then our company grew and more and more users started working - since Corona, many of them also remotely from the home office and the chaos took its course: Worst case was a move process of a ~90GB folder that was synced to the home office with the nextcloud client on >20 laptops. It took days until the synchronization was complete on all clients. In the middle of this process, the move was aborted and the result was named 2 and people started working in both. This happened several more times with other folders, which were then suddenly in places where nobody could find them again. The server was due to be moved anyway, which meant that in addition to cleaning up the data jumble, we also wanted to make a clear cut in rights management.
So a 3-node nextcloud cluster was built and the lessons learned from the past, that we are forced to limit user rights as the number of users increases, were also incorporated into the implementation. It is now no longer possible for the broad mass of users to delete or move data. For this purpose, we first defined a structure with Groupfolders and within this structure we assigned the DELETE right only to a few admin users who actually hardly work in the nextcloud anyway. Furthermore, we wrote a script that executes a delete command every 30 minutes via curl on all files or folders that have a “delete” at the beginning of their name (find ${GROUPFOLDER_PATH}[[:digit:]]* -iname “delete*”). This made deletion a more deliberate process and the files could be found in the admin user trash folder in case of an emergency. This worked wonderfully until v29…
…then came v30, in which the renaming of files was bound to the delete right, which means that this differentiation between “dangerous change” (delete or move) and “not so wild” (rename), which is so important for us, no longer applies. I know that it is understandable that a rename can also be seen as a “copy to the new file name and delete the old file”, but removing this feature without replacement is really hard - a way to differentiate would be much more user-friendly.
Many thanks in advance for any constructive feedback.