I recently had the need to configure a samba share on a linux box running Scientific Linux and I ran into a very annoying problem. I'm not going to explain all the details about how to configure the samba server and configure it (there are quite a few tutorials around for that, and I actually used Webmin which makes it very easy).
So after configuring everything, setting permissions and creating a user with simple password authentication, I was able mount the share on my mac but no contents were shown, not a single file.
I decided to debug more and checked the system log under
/var/log/messages
to see if there were any messages from smbd (the samba daemon). And in fact there were, I could see a lot of lines like this:
Nov 21 12:10:28 mymachine smbd[11558]: [2012/11/21 12:10:28.387715, 0] smbd/dir.c:304(dptr_close)
Nov 21 12:10:28 mymachine smbd[11558]: Invalid key 0 given to dptr_close
After googling for this for quite a while I realized a lot of people had already stumbled upon this error but none of the solutions were working for me. When I reached out for help my sysadmin colleague here at work immediately suggested that SELinux might be blocking access to the share. So we quickly tried to set it to "permissive" mode temporarily by doing
# setenforce 0
This works on RedHat linux flavors, in other distributions might have to do
# echo 0 >/selinux/enforce
(set it to 1 to enable back again). After doing this the share suddenly worked perfectly.
Configuring SELinux permanently
Regarding SELinux, the commands above will disable it but only until the next reboot. If you want to set it to permissive mode permanently, look for the file
/etc/selinux/config
(in RedHat distros) and change the line
SELINUX=enforcing
to
SELINUX=permissive.
Keep in mind that disabling SELinux might not be advisable for security reasons.
I also found another solution which is probably the best one since it doesn't require you to disable SELinux. In my case this is not a problem because the machine is pretty well protected behind a firewall and it's only used internally, but your case might be different. I didn't explore these as deeply but I'll leave a couple of links here if you want to learn more about it:
- Configuring Samba with SELinux - http://danwalsh.livejournal.com/14195.html
- Understanding SELinux, Part 7 - http://www.fosteringlinux.com/2010/01/selinux-part-7/
Let me know if this helped by leaving a comment!
I hit this recently on RHEL 6.10 trying to access a Samba share from OSX.
What worked for me is using the public_content_t SELinux context (general catch-all context for file sharing like NFS, SMB, HTTP)
chcon -R -t samba_share_t /path/to/share
What worked for me was setting public_content_t – it’s good for Samba but should also extend to NFS and H TTP sharing as well.
chcon -R -t public_content_t /path/to/share
Nice Posting….
Hi Deri7e,We̵b;be all well, thanks for asking. I’ve been bad about blogging for quite a while, but I plan to do better starting next month.We had a wonderful, fun- (and bus-) filled summer. I hope you did, too.
It is simple enough to apply the correct label to the share – from the samba_selinux manual page:
——8<——-
samba_share_t
use this label for random content that will be shared using samba
——8<——-
So, you can label the share as follows:
# chcon -R -t samba_share_t /path/to/share
Time to stop disabling SELinux everywhere guys
Cheers,
Toki
[…] 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 […]
Yes! This was the problem. SELinux may be for security, but it has only ever been a hinderance for me.