Samba 4.1 process_usershare_file: stat of /var/lib/samba/usershares/share failed. even though user can list that folder and stat file

samba4

I've got two identical users, one can access the share while the others not able to. The share's name is storage_photos, it's located in the folder /storage/photos/.

$ getfacl /storage/photos
getfacl: Removing leading '/' from absolute path names
# file: storage/photos
# owner: root
# group: photos
user::rwx
group::rwx
group:photos:rwx
mask::rwx
other::r--
default:user::rwx
default:group::rwx
default:group:photos:rwx
default:mask::rwx
default:other::r--

The two users in question are both members of the photos group:

$ groups john
john : john sambashare photos

$ groups lisa
lisa : lisa sambashare photos

And as of their membership in the sambashare folder they're able to list /var/lib/samba/usershares/:

sudo -u lisa ls -ltha /var/lib/samba/usershares/
total 24K
drwxrwx--T 2 root sambashare 4.0K Oct 25 17:06 .
-rw-r--r-- 1 root root        125 Oct 25 17:06 storage_photos

With this in mind it's strange to find that one user fails to access the share while the other succeeds:

smbclient //Server/storage_photos -U lisa%pass
Domain=[ONE] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
tree connect failed: NT_STATUS_ACCESS_DENIED

smbclient //Server/storage_photos -U john%pass
Domain=[ONE] OS=[Unix] Server=[Samba 4.1.6-Ubuntu]
smb: \>

On the server side the failure, with logging level 2, looks like:

[2015/10/25 23:12:20.646681,  0] ../source3/param/loadparm.c:4365(process_usershare_file)
  process_usershare_file: stat of /var/lib/samba/usershares/storage_photos failed. Permission denied
[2015/10/25 23:12:20.649381,  2] ../source3/smbd/service.c:407(create_connection_session_info)
  guest user (from session setup) not permitted to access this share (storage_photos)
[2015/10/25 23:12:20.649437,  1] ../source3/smbd/service.c:550(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

Meanwhile the success is a boring:

[2015/10/25 23:14:30.321507,  2] ../source3/smbd/service.c:856(make_connection_snum)
  device (ipv4:192.168.1.5:46134) connect to service storage_photos initially as user john (uid=1000, gid=1000) (pid 5297)
[2015/10/25 23:16:10.409218,  1] ../source3/smbd/service.c:1130(close_cnum)
  device (ipv4:192.168.1.5:46134) closed connection to service storage_photos

Now the interesting part from the failure is the following: process_usershare_file: stat of /var/lib/samba/usershares/storage_photos failed. Permission denied. Why would the access fail even though the user can stat the file:

sudo -u lisa stat /var/lib/samba/usershares/storage_photos
  File: ‘/var/lib/samba/usershares/storage_photos’
  Size: 125             Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d      Inode: 137795      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-10-25 17:06:46.704318935 +0100
Modify: 2015-10-25 17:06:46.700318935 +0100
Change: 2015-10-25 17:06:46.700318935 +0100
 Birth: -

From this one would draw the conclusion that for some reason samba isn't using the correct unix user to stat the file when lisa tries to log in but is when john does.

Both john and lisa can ssh to the machine. The machine does have libpam-smbpass installed as prescribed in this stack overflow question. But having restarted the server the issue persists.

All of this is using the following, very default, Ubuntu 14.04 smb.conf. The shares are defined by ZFS filesystems having the sharesmb parameter on.

[global]  
        workgroup = ONE  
        server string = %h server (Samba, Ubuntu)  
        server role = standalone server  
        map to guest = Bad User  
        obey pam restrictions = Yes  
        pam password change = Yes  
        passwd program = /usr/bin/passwd %u  
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .  
        unix password sync = Yes  
        syslog = 0  
        log file = /var/log/samba/log.%m  
        max log size = 1000  
        dns proxy = No  
        usershare allow guests = Yes  
        panic action = /usr/share/samba/panic-action %d  
        idmap config * : backend = tdb

Best Answer

For some reason reinstalling winbind on the server solved the issue, but not immediately. As if there was some caching going on with the authentication. So the solution is to run the following and then chill out for a while.

sudo apt-get remove winbind && sudo apt-get install winbind

I'm terribly sorry but I can't think of a reason why this would solve the issue when restarting winbind didn't, because apt should preserve config files as long as you're not purging a package.