Repository navigation
Renamed folders are re-created as empty folders #10122
Description
⚠️ Before submitting, please verify the following: ⚠️
- This is a bug, not a question or a configuration issue.
- This issue is not already reported on Github (I have searched for it).
- Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
- I agree to follow Nextcloud's Code of Conduct
Bug description
After a massive renaming of subfolders, clients are randomly re-creating empty versions of these folders using the previous folder name.
...
Steps to reproduce
- Folder name is updated
- Client comes online and syncs but no longer finds a folder with the previous folder name
- Client creates an empty folder which has the previous name of the folder
Expected behavior
The folders should not be re-created.
...
Which files are affected by this bug
Subfolders only
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Installation method
Official Windows MSI
Nextcloud Server version
32.0.11
Nextcloud Desktop Client version
33.0.5
Did this occur after an update or on a clean installation?
Minor version update (i.e. 33.0.0 → 33.0.1)
Are you using the Nextcloud Server Encryption module?
No
Are you using an external user-backend?
- Default internal user-backend
- LDAP or Active Directory
- SSO - SAML
- Other
Nextcloud Server logs
Additional info
No response
Activity
mgallien commentedon Jun 8, 2026
@lraven456 we need logs from you to be able to understand what may be happening
can you send us a debug archive ?
lraven456 commentedon Jun 8, 2026
@mgallien github is not letting me upload the archive at this time. Is there another way for me to send it?
bigretromike commentedon Jun 11, 2026
@lraven456 yes, unzip the debug package, pick the log from the time the issue occurs.
Also this is happening for us to. There was similar issue with "ghost" folders/files.
If user create folder (use existing one) and rename it few times im not sure if its propagation window or not but its end up that other clients using vfs (not sure if its vfs only issue) dont see final rename and as soon as they detect file is missing from server the client recreate folder structure folders and subfolders without any files.
In my case 1 client was rectreating folders as soon as I was deleting them via WebUI.
after updating client (which I was hoping was the issue) and deleting empty folder on his end, another client started doing this but this client was up-to-date, once again, removing those folders/structures on his end stop with recreating it.
I'm not sure if its just a progagation issue co slower clients lost the infromation about those folders being deleted.
In my case the initial "remove/rename" was made on other client (via windows vfs)
In case someone has issue with it, the fastest way to see who is doing it is logon via webui, click on details on the folder and there will be information who created this non-existing folder.
robinetmiller commentedon Jun 17, 2026
Also seeing this behaviour or very similar. The process flow in our case is file moves or deletes, not renames, but seems likely they're all the same cause.
General Facts
.sync_xxxxxx) on Bob's machine temporarily resolved symptoms (1-2 days), but it crept back in with new files.Symptoms
Given a shared folder in External Storage S3-type bucket (
/bucket/)And server folder structure:
/bucket/folder1/folder1.1//bucket/folder2//folder1/folder1.1/example/fileA.ext/folder1/folder1.1/example/to/folder2/example//folder1/folder1.1/example/and/folder1/folder1.1/example/fileA.extMy assumption is that Bob's computer does not get properly informed about the move/delete (or doesn't record it correctly, or local multithread async nonsense, etc). It then sees the local files exist as if new files and pushes them to the server.
Suspicious the First
Users can have multiple paths to the "same" folder due to groups and group folder sharing.
eg:
/bucket/folder1//bucket/folder1/folder1.1//folder1/folder1.1//folder1.1/Haven't seen anything in the docs saying overlapped groups with folder sharing is a Very Bad Idea, but my spidey senses say it could be related.
I have seen at least one instance in the server log where it uses one path for the folder create and another path for the file create like:
MKCOL
/remote.php/dav/files/alice/folder1/folder1.1/example/PUT
/remote.php/dav/files/alice/folder1.1/example/fileA.ext)On the other hand, these users, groups, and shares have, AFAIK, been unchanged since before this started. Could be wrong though.
Suspicious the Second
Sometimes the repopulated zombie folders are files and folders, sometimes empty folders.
Guess: empty zombie folders happen when being repopulated from a virtual folder and non-empty when downloaded because the file on Bob's computer isn't actually there.
lraven456 commentedon Jun 22, 2026
@mgallien could you please provide a link for a Nextcloud folder for me to upload the bug reports into? I prefer to not post the reports directly to github.
nilsding commentedon Jun 22, 2026
@lraven456 You may upload your debug archive to our company instance using this link: https://cloud.nextcloud.com/s/ekxb56ttqtCbHkK
please make sure to reproduce the issue at least once before creating the debug archive
lraven456 commentedon Jun 22, 2026
@nilsding Thank you. I attached the client logs as well as a text file with a more detailed explanation plus the logs from the SQL server.
IwishIcanFLighT commentedon Jul 25, 2026
I just noticed that I had the exact same issue on my server (v34.0.2, Windows client v33.0.2). A couple of weeks ago I renamed a folder containing 17 subfolders and 166 files (mostly PDFs), about 250MB total. About 90% of the files were deleted, the rest somehow survived the bug.
Exploring my NC Trash Bin folder on the WebUI, I found the wrongly deleted files. Their root path was still the old parent folder names, and attempting to restore them from the WebUI seems to delete them for good (or at least attempt to move them somewhere, but I could not see them anywhere after trying the restore button).
Fortunately I was able to restore all my files thanks to my 3-2-1 backup in place, but from what I found this bug seems to be quite severe if it ends up deleting files.
bigretromike commentedon Jul 28, 2026
I dont think we had the issue you describe.
It would be best to make new issue with all the log files etc.
If client delete wrong files this is a major issue that no one want to encounter