Locale-dependent synchronization issue with Linux client

I have encountered a weird problem with my desktop client that I am able to work around, but I am seeking help in understanding this.

I recently noticed that files and folders containing German umlauts (äöü etc.) would no longer synchronize with my Nextcloud server. Existing files and folders would no longer get updates, and new files and folders would not be synchronized to the server, nor synchronized from the server.

The client is an AppImage version 3.6.2 on a KDE neon 5.26 system (Linux). Investigating the desktop client’s logs in ~/.config/Nextcloud/logs, I found tons of messages around “The filename cannot be encoded on your file system.” Evidently, some problem with filename encoding prevented my files and folders from being synchronized. (The file system in question is ext4, and I have loads of files and folders with umlauts, it works perfectly fine.)

The workaround is to run the client like so:

LC_ALL=en_US ./Nextcloud-3.6.2-x86_64.appimage

But the question is, why does it not work as expected without overriding the locale?

Here’s my locales:

$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

I tried the above command with each and every of the locale variables, e.g. LANG=en_US ./Nextcloud-3.6.2-x86_64.appimage and really did this with all those variables, but the only thing that works is setting LC_ALL to en_US.

I wondered why the problem appeared now and not previously. I had recently re-installed my system using the latest KDE neon image, and obviously, some locale-related problem was introduced at that time.

But why does it happen in the first place? What’s causing nextcloud-client to be unhappy with umlauts, while everything else works fine, and why do I have to set the “brutal” variable LC_ALL rather than fine-tuning some other locale setting?

I cannot set LC_ALL system-wide as this will obviously mess with all my locale and regional settings, and I’m totally fine with invoking the desktop client with the prefix, but I’d really like to understand why it’s not one single locale setting that does the trick and why it has to be LC_ALL.

Any thoughts on this would be appreciated.

1 Like