OS X Terminal: -bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory Fix

last updated in Categories , , ,

I am a new Apple OS X Mabbook user. I am getting an error which read as follows when I connect to any remote Linux/Unix/BSD server or machine through OS X ssh Terminal app:

ssh user@server1.cyberciti.biz
Last login: Wed Mar 26 08:45:36 2014 from 1.2.3.4
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

How do I fix this error?

[donotprint][/donotprint]This warning or error is part of both OpenSSH server and OS X ssh terminal client issue. It can be fixed using various methods.

Understanding LC_* environment variables

Type the following command on remote server to display of all locales supported by Glibc:

$ locale -a

Next, type the following command to display settings on your local system (OSX/Unix/Linux based desktop):

printenv
echo "$LC_CTYPE"

Sample outputs:

UTF-8

The above commands display the country and language names, the character encoding used by the locale. Your local ssh client is sending your LC_* environment variables to remote sshd server. In other words, SSH will try to set every LC_* variable you have set on your local OSX system on the remove server too. Here is an example of such problem:

Fig 01: warning setlocale lc_ctype cannot change locale (utf-8)
Fig 01: warning setlocale lc_ctype cannot change locale (utf-8)

Fixing the LC_CTYPE: cannot change locale (UTF-8) error on Linux/OS X

This can be fixed as follows.

Method #1: If you are using the Terminal app on OS X

If you are using the ‘Terminal’ app then click on

Terminal > Preferences > Select Terminal type such as Basic (default) > Advanced tab

Make sure that the ‘Set locale environment variables on startup’ is unchecked as follows:

Fig.02: Fixing OS X terminal by unsetting 'Set locale environment variables on startup' check box
Fig.02: Fixing OS X terminal by unsetting ‘Set locale environment variables on startup’ check box

Here is another screenshot from MacOS X v10.11.6:
Fig.03: Unsetting 'Set locale environment variables on startup' check box on OS X EI Caption
Fig.03: Unsetting ‘Set locale environment variables on startup’ check box on OS X EI Caption

You must close all ssh session and relaunch Terminal app.

Method #2: Preventing OpenSSH Client from sending the LC_* variables on OS X / Linux / Unix desktop

Edit /etc/ssh/ssh_config or /etc/ssh_config file, enter:

$ sudo vi ~/.ssh/config

Remove or comment out as follows:

#SendEnv LANG LC_*

Save and close the file.

Method #3: Install required locale on the remote server

Finally, you can fix this problem either installing the desired locale using the localedef command, or consider choosing a different locale in locale/remote system:

# localedef -i en_US -f UTF-8 en_US.UTF-8

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin, DevOps engineer, and a trainer for the Linux operating system/Unix shell scripting. Get the latest tutorials on SysAdmin, Linux/Unix and open source topics via RSS/XML feed or weekly email newsletter.

26 comment

  3. The /etc/ssh_cofig fix worked for me. Thanks!
    It was quick, nice, and easy change.

    In your post, You should change
    sudo vi ~/.ssh/config
    to
    sudo vi /etc/ssh_cofig
    .

    Regards,
    Devashish.

  8. Just wanted to say thanks.
    Using iTerm2 – but there’s no option to unset locale variable on startup in the GUI, so the /etc/ssh_config edit was the way to go – and worked.

    1. In iTerm2 it is done under Preferences -> Profiles -> Terminal
      Uncheck the box “Set locale variables automatically”

  10. Hi, when I tried the third method, I get the error
    “Can’t open charmap file UTF-8: No such file or directory”. Any idea on how to fix this?

  12. Hi thanks very much
    Method #2 worked for me but
    i did
    nano /etc/ssh_config to
    fix my error ; now i don’t have the problem again when i ssh into my remote machine.
    Thanks!

  19. Hi, thanks for the article.
    I was facing this issue, not always, while connection to an EC2 Linux instance through macOS console app, and that small checkbox made all the difference.

    Still, have a question? Get help on our forum!

Tagged as: Tags , ,