Last night, I threw together a quick Samba server on a RHEL 6.4 machine at home. (I’m running RHEL, but you’d almost certainly have an identical experience on CentOS.) I set up user homedirs accessed over Samba, and was able to authenticate properly from my Mac laptop.
However, I ran into an issue where I could connect okay, but the mounted share showed as empty. I couldn’t copy files in, and any files already there didn’t show up. A bit of Googling suggests this isn’t an uncommon problem. The share looked blank/empty.
Checking /var/log/messages, I saw a bunch of these entries:
May 9 22:04:02 c6100-n4 smbd[8537]: [2013/05/09 22:04:02.949679, 0] smbd/dir.c:315(dptr_close) May 9 22:04:02 c6100-n4 smbd[8537]: Invalid key 0 given to dptr_close
Googling this, I found an article suggesting that it’s caused by SELinux, and another from a SuSE user having the same issue with AppArmor. I really didn’t like the suggestions to disable these services, though; it feels akin to disabling a firewall because it’s too complicated to configure.
And, if you know where to look (man samba_selinux), it’s actually easier to fix this the right way than to persistently disable SELinux:
If you want to allow samba to share users home directories, you must turn on the
samba_enable_home_dirs boolean.setsebool -P samba_enable_home_dirs 1
It’s annoying that the error in /var/log/messages doesn’t convey anything useful, but I can understand why this behavior would be prohibited by default. Why should a daemon be allowed to read users’ home directories out of the box?
Running the setsebool -P samba_enable_home_dirs 1 command (note that -P makes it persist, and that doing so updates on-disk policies, which takes a moment), everything works great. My clients can see the shares just fine, the cryptic errors aren’t being logged, and SELinux remains in enforcing mode.