3

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
Rovanion
  • 609
  • 3
  • 7
  • 22

2 Answers2

2

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 the smb.conf file:

usershare max shares = 0

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.

wazoox
  • 6,918
  • 4
  • 31
  • 63
  • I found your answer in more detail here: https://github.com/gdiepen/volume-sharer/issues/4#issue-342335452 with information about the windows client defender that is causing those log messages: https://unix.stackexchange.com/a/276593/116152 – Ron K. Feb 23 '23 at 23:01
1

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.

Rovanion
  • 609
  • 3
  • 7
  • 22