Nextcloud version Hetzner hosted 29.0.5.1
Operating system and version: unknown
Apache or nginx version: unknown
PHP version: unkown
The issue you are facing:
After a user has shared a folder it was always possible to rename or move the reference folder to another location/name. Since two weeks an error comes up once I try one of the operations. An generic error comes up "Server replied “500 Internal Server Error” to MOVE . It does occur in every client (Web, MacOS, iOS, Windows) and it does not matter if I shared the folder or someone else shares the folder.
Is this the first time you’ve seen this error? Y
Steps to replicate it:
Create a folder
Share the folder with another user
Another other tries to move or rename the folder
I cannot access any logfile or config file or at least I’m not aware that it is working with the Hetzner installation.
The issue still persists and it is very annoying, since I cannot organize my fotos anymore. All shared folders resides in the default root location and cannot be moved or renamed.
Has anyone any idea how to approach this? Do you have suggestions which logs might help out? Do yo know if Hetzner can help here?
Nextcloud: 30.0.4
Operating System: Linux 5.15.152-1-pve x86_64
PHP Version: 8.2.27
Log entry for move attempt:
[webdav] Error: Node for share not found, fileid: 495281
MOVE /remote.php/dav/files/user/InstantUpload%20(2)
from 192.168.123.45 by user at Jan 6, 2025, 8:02:07 AM
Log entry for rename attempt (same - also a move operation):
[webdav] Error: Node for share not found, fileid: 495281
MOVE /remote.php/dav/files/user/InstantUpload%20(2)
from 192.168.123.45 by user at Jan 6, 2025, 8:04:09 AM
This solved the problem actually. Thanks a lot for sharing your solution.
Do you know what this function actually does? I got an output with a list of shared with their original name before renaming. Will the command remove only the share?
Thanks again!
It clears lingering entries in the database which should have been deleted with the corresponding file but somehow weren’t (so: orphans).
Every file id the command gave me returned no result with the occ file:info command and the few I checked, indeed, didn’t exist anymore.
From my understanding, yes, a share designates only the rights given to someone on a file they don’t own so not the files themselves.