I am running Samba on a CentOS server, and I am experiencing a problem where it allows me to connect to the server and see a share, but shows the share as an empty directory. I find this behavior strange.
Here is the stanza in my smb.conf for the given share:
[seanm]
path = /home/seanm
writeable = yes
valid users = seanm, root
read only = No
Here's what I see on the server side:
[seanm@server ~]$ ls -l
-rw-r--r-- 1 seanm seanm 40 Jan 4 13:45 pangram.txt
And yet:
[seanm@client ~]$ smbclient //server/seanm -U seanm -W WORKGROUP
Enter seanm's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.33-3.29.el5_5.1]
smb: \> ls
. D 0 Fri Jan 7 10:08:55 2011
.. D 0 Fri Jan 7 07:58:31 2011
58994 blocks of size 262144. 50356 blocks available
This behavior is present on both a Windows client and a Linux client system. The behavior is present with the firewall on and with the firewall off, so it's not that. Neither /var/log/messages nor /var/log/secure have any complaints about Samba. If I mkdir a directory in the share, that shows up, as well as subdirectories, but files still do not appear.
I doubt that SELinux is a problem: just in case, here are the relevant settings.
[root@server ~]# getsebool -a | grep samba
samba_domain_controller --> off
samba_enable_home_dirs --> on
samba_export_all_ro --> off
samba_export_all_rw --> off
samba_share_fusefs --> off
samba_share_nfs --> off
use_samba_home_dirs --> on
virt_use_samba --> off
What am I doing wrong here, and what can I do to fix it?
Edit: SELinux probably is the problem, judging by the fact that the issue goes away when I set SELinux to "permissive" or issue setsebool -P samba_export_all_rw on
- both of which are unacceptable for production environments. What the heck kind of context does a directory need to have on it for Samba users to actually get files from it? I consider rolling your own rules and/or context to be deeply sub-optimal.
Problem seems to be solved now. It was SELinux; the context for the home directory was not correctly set.
Problem is exhibited.
Problem is not exhibited for seanm, but is exhibited for larry.
My best guess is that it's something with Cobbler: 'larry' and 'seanm' were both created during the install process with Cobbler, and I notice that system_u isn't really a proper context for them either, since it's not what users created with
useradd
get:I guess it's time to grep through Cobbler documentation.
Did you try ....