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-1
charset, and is happy; - Linux gets its
utf-8
charset, and is happy; preserve case
s make sure that filenames aren’t changed while moving files across machines;- disabling
case sensitive
avoid 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
:
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.
SELinux
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.