Let’s face it: SMB/CIFS comes in handy plenty of times. Works great under Linux, works great with Windows, and if it’s configured properly it’s fun times for everyone. There are multiple potential behavioural problems though, mostly involving charsets.
Samba charset (and filesystem) setup
While I’ve been successfully using
iso-8859-1 by default for a long time in my Samba servers, until recently I also used the same charset in the *nix filesystem, which brought all kind of oddities. 20/20 hindsight, as per usual. In
smb.conf, you can configurn though you can specify different charsets to make everyone happy:
[global] dos charset = iso-8859-1 unix charset = utf-8 preserve case = yes short preserve case = yes default case = lower case sensitive = no
This has multiple advantages:
- Windows gets its
iso-8859-1charset, and is happy;
- Linux gets its
utf-8charset, and is happy;
preserve cases make sure that filenames aren’t changed while moving files across machines;
case sensitiveavoid weird behaviour under Windows.
This is the configuration I’ve been running for years, sharing files across Windows/Linux/OS X machines since Windows XP, and has been working perfectly.
Changing filesystem charset
If you’re switching the unix charset though, you might need to convert existing files/directories to the new charset. Cue in
convmv -f <from_charset> -t <to_charset> -r --preserve-mtimes <dir>
In my case:
convmv -f iso-8859-1 -t utf-8 -r --preserve-mtimes .
With this simple command I was able to mass rename thousands of files in one go. Note that you also need the
--notest parameter to actually apply the changes, and not just list the files in a dry run.
While playing around Centos I stumbled into SELinux problems I wasn’t prepared for. Consider the following:
[Share] comment = Personal share path = /home/<username>/share/ guest ok = no browseable = yes writable = no create mask = 0660 directory mask = 0775 write list = <username>
Supposing the path actually exists, that the username is added to the samba user database and that the password is correct, everything should work fine. Except that it mostly likely won’t, because we need to configure SELinux on top of everything else:
restorecon -R -v /home/<username>/share/ chcon -R -t samba_share_t /home/<username>/share/
That’s all there is to properly setup and have the content accessible. Contrary to what other people claims, you don’t have to increase permissions in the samba path tree. A
0700 on the
/home/<user> works perfectly fine.