Howard Rogers
Cadet
- Joined
- Aug 20, 2015
- Messages
- 6
FreeNAS 9.3, and I am trying to store files on my FreeNAS datasets with foreign characters in their name (i.e., things like Ä,é,ë,ß,â,ö,ç). The files are shared via CIFS, and all my Windows and Linux clients can create such files and they display perfectly in their respective browsers. For example:
But, if I use the FreeNAS console to poke around in the shell, I get this:
Now, if I ssh into the freenas box, the same issue arises:
But I can at least fix that:
However, when I try the same thing on the original console (rather than in a remote terminal connected via ssh), I don't achieve the same degree of success:
So my questions are:
1. Is anything wrong here? That is, does the file system genuinely store the correct characters and this is simply a matter of how the console can (or can't) display them accurately?
2. Is there anything I can do to get the console displaying the characters correctly? That is, how does one set LC_ALL in the .sh shell? (I only know to invoke the bash shell and issue export commands, I'm afraid).
3. Is the failure to display shown in that last screenshot just an artefact of the font that the console uses... and is there anything I can do about that?
I suppose the fundamental question is that #1: if my Windows and Linux clients are happy with what they store, and are happy displaying it back, is there any danger in allowing the backend to not display them correctly without mucking about with shells, locales and the like?
Any guidance appreciated.

But, if I use the FreeNAS console to poke around in the shell, I get this:

Now, if I ssh into the freenas box, the same issue arises:
Code:
hjr@dirac ~ $ ssh root@192.168.137.215 root@192.168.137.215's password: [root@freenas] ~# ls -l /mnt/MUSICVOL/SHARED_MUSIC/Classical/ total 14 drwxrwxrwx 5 nobody guest 5 Aug 20 22:03 ./ drwxrwxr-x+ 3 root guest 4 Aug 20 02:26 ../ drwxrwxrwx 2 nobody guest 2 Aug 20 22:03 Arvo P??rt/ drwxrwxrwx 2 nobody guest 3 Jun 26 22:29 F??r Lennart in memoriam (Kaljuste)/ drwxrwxrwx 2 nobody guest 2 Aug 20 21:52 ??????????????/
But I can at least fix that:
Code:
[root@freenas] ~# /bin/bash [root@freenas ~]# export LC_ALL=en_AU.UTF-8 [root@freenas ~]# ls -l /mnt/MUSICVOL/SHARED_MUSIC/Classical/ total 2 drwxrwxrwx 2 nobody guest 2 20 Aug 22:03 Arvo Pärt drwxrwxrwx 2 nobody guest 3 26 Jun 22:29 Für Lennart in memoriam (Kaljuste) drwxrwxrwx 2 nobody guest 2 20 Aug 21:52 Äéëßâöç
However, when I try the same thing on the original console (rather than in a remote terminal connected via ssh), I don't achieve the same degree of success:

So my questions are:
1. Is anything wrong here? That is, does the file system genuinely store the correct characters and this is simply a matter of how the console can (or can't) display them accurately?
2. Is there anything I can do to get the console displaying the characters correctly? That is, how does one set LC_ALL in the .sh shell? (I only know to invoke the bash shell and issue export commands, I'm afraid).
3. Is the failure to display shown in that last screenshot just an artefact of the font that the console uses... and is there anything I can do about that?
I suppose the fundamental question is that #1: if my Windows and Linux clients are happy with what they store, and are happy displaying it back, is there any danger in allowing the backend to not display them correctly without mucking about with shells, locales and the like?
Any guidance appreciated.