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
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.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.
The error message from "process_usershare_file" is very misleading, and is related to user_shares, that are intended to allow a local user logged on to the GUI to share folders with others workstations, windows-style. This setting is completely irrelevant on dedicated samba servers (where nobody ever works at the local console) but is unfortunately on by default on most distros, and often causes spurious errors like these. Worse, the stream of errors even slows down the server at times (it's very noticeable on fast, 10GigE connected servers).
To get rid of this message, add this to the
[global]
section of thesmb.conf
file:And restart smbd to enable it. It will at least prevent Samba clients from trying to access non-existent user shares and spam your logs.