Missing locales on remote system

Since this is now the third time I ran into this issue and it always mislead me in a completely wrong direction, I’ll finally document it.

So, you are SSH-ing into a remote system (typically Debian or a derivative), then you you install a package or do something else that triggers some access to the locales (UNIX style localization for shell commands etc.) and you see messages similar like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_CH.UTF-8",
LC_NAME = "de_CH.UTF-8",
LC_PAPER = "de_CH.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory

You might assume that you did not install all the required locales. In the example above I saw these settings of de_CH.UTF-8 on an english only system. So you could generate/install the missing languages i.e. with „dpkg-reconfigure locales„. But note the mentions of „(unset)“ above. Even with all the required locales you still will see these messages.

So, what is the cause of this mess? Nothing is wrong with your server. The actual culprit is a misconfiguration on the host you are running the SSH session from. It has these settings and newer SSH clients provide the comfort functions of exposing your local locale settings to the remote system.

In an ideal scenario this allows you to talk to your server in your native language. Unfortunately some newer linux distributions like Ubuntu starting from 12.04 (it has also been reported on MacOS X) don’t set all of these variables leading to these warnings on system that want these to be set.

TL;DR: The quick solution is to comment the setting in your /etc/ssh/ssh_config file that causes the exposure of these environment variables to your server:

# SendEnv LANG LC_*

Discussion Area - Leave a Comment