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.
You sir are a god among men. I’ve been banging my head against this same problem off and on for a week now and just didn’t know what to google. After learning about samba logging I found the error and here is my saving solution. Thank you SO MUCH for posting this!
Thank you!!! If one would read the all the file… Thank you very much!!!
Hi, Great post and makes sense. One question I have is: can you apply the the same logic (allow ‘home’ directory SELinux permissions) to any directory on the file system?
I have a drive active as a file server and the files under /home/DATA need to be shared. We’ve had our teething issues with MACs in the office but things have appeared to settle a bit now EXCEPT I still see there errors in the log file for 1 mac box.
Can you add a specific directory to an SELinux+Samba security policy?
Davened, I’m not sure I can answer your specific question. I think the answer is “Yes,” but I’m not sure I know enough about SELinux/Samba, nor your exact situation, to be able to help completely.
Most SELinux policies are specific to certain directories, so what you’re doing should be possible. You can use ls -Z to list the security contexts, and Dan Walsh is pretty good about blogging information about his work on SELinux for RHEL/Fedora. This post in particular might be helpful.
The SELinux for Mere Mortals talk given at Red Hat Summit every year (link is to a Youtube video of the talk) is pretty helpful for making sense of much of this, if you haven’t seen it before. It’s a bit lengthy, but it helped me significantly in figuring out how this works.
Also works for FREENAS/FREEBSD (CIFS share dialog – enable home directories and enable home directory browsing are both options)
does not help me
Feb 13 12:11:48 hostname smbd[17360]: [2014/02/13 12:11:48.157114, 0] smbd/dir.c:317(dptr_close)
Feb 13 12:11:48 hostname smbd[17360]: Invalid key 0 given to dptr_close
setsebool -P samba_enable_home_dirs 1
setsebool: SELinux is disabled.
What fixed this for me was setting the public_content_t SELinux context (this should also work for NFS and HTTP access).
chcon -R -t public_content_t /path/to/share