Error moving or renaming shared folder

[/details]

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:

  1. Create a folder
  2. Share the folder with another user
  3. 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.

Thanks and best regards,
Timm

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?

Thanks!

Also seeing this on a self-hosted instance.

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

I identified the same issue here on the dockerized version 29.0.8 :raised_hand_with_fingers_splayed:

After inspection, it does not happen on a fresh, unparametered container. I couldn’t trace it back to a config option though.

I’ll continue investigating and will make a new reply If I find anything relevant.

I found my solution here: Github Issue :tada:

Found it by searching the error message (obviously)

Turns out Nextcloud tried to access arbitrary shares to deleted files anytime someone tried to move a share (don’t ask me why :person_shrugging:).

Clearing those orphaned shares with occ sharing:delete-orphan-shares solved it for me.

This works assuming you have access to a command line, I couldn’t find an equivalent in the administration UI.

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!

1 Like

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.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.