4

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.

Brighid McDonnell
  • 379
  • 1
  • 7
  • 20

2 Answers2

3

Problem seems to be solved now. It was SELinux; the context for the home directory was not correctly set.

[seanm@server /home]$ ls -alZ
    drwx------  larry stooges  system_u:object_r:home_root_t    larry
    drwx------  seanm seanm    system_u:object_r:home_root_t    seanm

Problem is exhibited.

[seanm@server /home]$ chcon -hR system_u:object_r:user_home_dir_t /home/seanm
[seanm@server /home]$ restorecon -Rv /home/seanm
[seanm@server /home]$ ls -alZ
    drwx------  larry stooges  system_u:object_r:home_root_t        larry
    drwx------  seanm seanm    system_u:object_r:user_home_dir_t    seanm

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: 

[root@server /home]# useradd selinuxtest
[seanm@server /home]$ ls -alZ
    drwx------  larry       stooges     system_u:object_r:home_root_t        larry
    drwx------  seanm       seanm       system_u:object_r:user_home_dir_t    seanm
    drwx------  selinuxtest selinuxtest user_u:object_r:user_home_dir_t      setest

I guess it's time to grep through Cobbler documentation.

Brighid McDonnell
  • 379
  • 1
  • 7
  • 20
0

Did you try ....

browseable = yes
c1tadel1
  • 51
  • 2