Illegal characters in filename paralyzes Sync-Client


first things first.
Thank you for your great work!

I’m a little bit confused.
I’m running NC9 for a customer on a Ubuntu-Server.
But the problem is a client or better any client.
I think its a design flaw in the client. But I let myself be instructed.

If I use a slash / in a filename the client is not able to upload this file.
Becase the / disturbs the url which contains off slashes.

The Client 2.2.4 on Windows and Mac show both an unspeecific error like “unknwon” error.
German: Beim Öffnen eines Ordners ist ein Fehler aufgetreten. Unbekannter Fehler

Nothing the in activity logs.
Only in the main Log (F12) I was able to fine the cause. The file was hidde deep inside some directories.

The Question is not what the problem is.
The Question is why does it need to happen this way?

I think there are two ways.

A) show the user an helpfull information. use the internal blacklist funktion. This way the information is shown in the activity log. This should be easy to do.

B) why not to encode the filename? mask the “bad” characters in each OS?

The same Problem should happen if I create a file with a backslash on mac and sync it to windows.



There should already be more comprehensible error messages:

If it still happens, please report it to the client-team:

(the client just gets a Nextcloud theming, not sure when NC has own developers for the client. If you can reproduce this problem with a OC client on OC, you can also report in the original repo:

I can confirm this problem when using the NC client on mac ( with NC11 (11.0.2) running on debian.

I know this thread is almost 1 year old, but I encounter the same behavior with one of my clients.

As soon as there is a single file that has a “+” sign in a filename (which is permitted under Windows), the sync client will refuse to sync further.

Wouldn’t it be a good idea to simply escape the unwanted characters in a way so it can be stored in the database and on the underlying server filesystem? Just comparing with Dropbox, that’s probably the kind of thing that they do, because my client was with them before and had no issue with their ~500 files bearing a “+” sign in the filename.

Also, the error displayed is somewhat cryptic and says nothing about using an illegal character in the filename.