Windows client doesn't sync characters like ě š č ř ž

Hello, I moved to next cloud and wanted to sync all my data into the server via Windows Client. I have Czech characters in names of files and folder like ě š č ř ž but read that similar issue is present for German or Swedish characters. Any folder or file which contains these characters is not sync from or to nextcloud via the Windows Desktop Client. It can be uploaded and downloaded via Web UI. It can also be uploaded using raw WebDAV access (through WinSCP).
Nextcloud server - docker based - postgres:15-alpine, redis:6-alpine, nextcloud:27-apache.
Nextcloud client - Version 3.9.1 (Windows)

I do not see any errors in either Server or Client logs.

Any suggestion on how to fix Nextcloud windows client welcome.

1 Like

Hello Jan.

I’ve just figured out that the root of sync problems on our side was using Lithuanian letters in folder / file names in this thread. It is also clear that files / folders are visible in the Web Browser, but not in File Explorer… At the moment we are changing all the naming as a solution, so that more or less only standard latin letters are used.

Are you sure that š and ž letters result in sync issues too though? We found out that they are working just fine and in fact they do belong to ASCII standard. Please double check this just in case.

Not sure if you use Group Folders, but on github using special characters in names is listed as a knows issues as well.

*Seems like issue with the support of letters beyond ASCII is going deep into various parts of Nextcloud and indeed many other applications.


  • After more tests and browsing github it became clear that Nextcloud client v3.9.1 indeed is behind issues with sync of files with special characters as well as Chinese and Cyrillic names… You can try reverting back to v3.9.0 and most likely things will start working again on your side. Tested it out on our sides and things are working again, without renaming everything to ASCII set.
1 Like


Reverting back to Nextcloud client v3.9.0 actually worked.

My case solved by reverting to client 3.9.0.
How to get this info to the devs properly so they can fix in next Client version?

There is an updated version 3.9.2 which has this bug fixed

Tested as well and confirming that 3.9.2 works! Thanks for quick resolution.