SOLVED User authentication problem with samba shares

[mortar]

Hello,

I'm new to freenas, and the initial steps haven't been without problems. One problem is with user authentication in samba shares:

Created two identical datasets, two users (and respective groups) and one samba share for each user. The first user can access/mount both shares (can't write to the second user's share, though), but the second user cannot access/mount any shares. Logging in through ssh works for both users. All the settings visible in the webgui appear the same for both datasets, users and shares as do the shares in smbd's config file. When the second user tries to access/authenticate a share smbd.log says NT_STATUS_ACCESS_DENIED. Tried changing the user password and rebooting the freenas server to no avail.

Is there some config file for samba which has the authentication info and/or share ownership mapping?

Right now, I'm using the latest stable release [FreeNAS-9.3-STABLE-201509022158], but initially I installed a version from May. I remember having problems with guest access to samba, but now a few upgrades later that appears to work fine.

 

[anodos]

• Post /etc/local/smb4.conf.
• Post getfacl output for both datasets. I.e. 'getfacl /mnt/tank/dataset1'

Enclose above output in [ code ] tags.

Did you inadvertantly disable password authentication for your second user?

Note that Windows won't let you use two separate sets of credentials for the same share from the same local user account on the windows client.

 

[mortar]

• Post /etc/local/smb4.conf.
• Post getfacl output for both datasets. I.e. 'getfacl /mnt/tank/dataset1'

Enclose above output in [ code ] tags.

Did you inadvertantly disable password authentication for your second user?

Note that Windows won't let you use two separate sets of credentials for the same share from the same local user account on the windows client.

I don't think I would have disabled password authentication. How would I check that? SSH with password auth works for both users.

Note that the datasets are with Unix permissions as that seemed to be the only way to get chmod to work under linux/mac clients.

smb4.conf

Code:

[global]
  server max protocol = SMB2
  encrypt passwords = yes
  dns proxy = no
  strict locking = no
  oplocks = yes
  deadtime = 15
  max log size = 51200
  max open files = 470315
  load printers = no
  printing = bsd
  printcap name = /dev/null
  disable spoolss = yes
  getwd cache = yes
  guest account = nobody
  map to guest = Bad User
  obey pam restrictions = yes
  directory name cache size = 0
  kernel change notify = no
  panic action = /usr/local/libexec/samba/samba-backtrace
  nsupdate command = /usr/local/bin/samba-nsupdate -g
  server string = FreeNAS Server
  ea support = yes
  store dos attributes = yes
  lm announce = yes
  time server = yes
  acl allow execute always = true
  acl check permissions = true
  dos filemode = yes
  multicast dns register = yes
  domain logons = no
  local master = yes
  idmap config *: backend = tdb
  idmap config *: range = 90000001-100000000
  server role = standalone
  netbios name = MYSERVER
  workgroup = WORKGROUP
  security = user
  pid directory = /var/run/samba
  smb passwd file = /var/etc/private/smbpasswd
  private dir = /var/etc/private
  create mask = 0666
  directory mask = 0777
  client ntlmv2 auth = yes
  dos charset = CP437
  unix charset = UTF-8
  log level = 1
  

[user2]
  path = /mnt/vol1/home-user2
  printable = no
  veto files = /.snapshot/.windows/.mac/.zfs/
  writeable = yes
  browseable = no
  vfs objects = zfs_space zfsacl aio_pthread streams_xattr
  hide dot files = yes
  guest ok = no
  nfs4:mode = special
  nfs4:acedup = merge
  nfs4:chown = true
  zfsacl:acesort = dontcare
  case sensitive = yes
  

[user1]
  path = /mnt/vol1/home-user1
  printable = no
  veto files = /.snapshot/.windows/.mac/.zfs/
  writeable = yes
  browseable = no
  vfs objects = zfs_space zfsacl aio_pthread streams_xattr
  hide dot files = yes
  guest ok = no
  nfs4:mode = special
  nfs4:acedup = merge
  nfs4:chown = true
  zfsacl:acesort = dontcare
  case sensitive = yes
  

[guesttest]
  path = /mnt/vol1/guesttest
  printable = no
  veto files = /.snapshot/.windows/.mac/.zfs/
  writeable = yes
  browseable = yes
  vfs objects = zfs_space zfsacl aio_pthread streams_xattr
  hide dot files = yes
  guest ok = yes
  nfs4:mode = special
  nfs4:acedup = merge
  nfs4:chown = true
  zfsacl:acesort = dontcare

getfacls:

Code:

# file: /mnt/vol1/home-user1
# owner: user1
# group: user1
  owner@:rwxp--aARWcCos:------:allow
  group@:r-x---a-R-c--s:------:allow
  everyone@:r-x---a-R-c--s:------:allow

# file: /mnt/vol1/home-user2
# owner: user2
# group: user2
  owner@:rwxp--aARWcCos:------:allow
  group@:r-x---a-R-c--s:------:allow
  everyone@:r-x---a-R-c--s:------:allow

 

[anodos]

There's actually no way to disable ACLs in freenas, you have a choice between erratic and somewhat broken permissions that let you chmod to further break permissions (CIFS and Unix), and functional ACLs (CIFS and Windows permissions).

 

[cyberjock]

There's actually no way to disable ACLs in freenas, you have a choice between erratic and somewhat broken permissions that let you chmod to further break permissions (CIFS and Unix), and functional ACLs (CIFS and Windows permissions).

+1

The only officially support configuration in FreeNAS for CIFS is Windows permissions (using ACLs). Nothing else is supported or expected to work, althrough there are ways to make it work, it could stop working at any time since it works by happenstance and not by design.

 

[mortar]

+1

The only officially support configuration in FreeNAS for CIFS is Windows permissions (using ACLs). Nothing else is supported or expected to work, althrough there are ways to make it work, it could stop working at any time since it works by happenstance and not by design.

Ack, so mixed client share (unix,mac,win) is not doable on freenas, but changing the permission type to windows did nothing to the second user authentication problem of the actual thread topic.

 

[anodos]

Ack, so mixed client share (unix,mac,win) is not doable on freenas, but changing the permission type to windows did nothing to the second user authentication problem of the actual thread topic.

Why isn't mixed client support not doable? ZFS acls make freenas behave more like a Windows server, and gvfs/ mount.cifs / smbclient / whatever work with real Windows servers. If NFSv4 acls break a Linux or Mac client, then it's a client problem, not a server problem.

 

[mortar]

Why isn't mixed client support not doable? ZFS acls make freenas behave more like a Windows server, and gvfs/ mount.cifs / smbclient / whatever work with real Windows servers. If NFSv4 acls break a Linux or Mac client, then it's a client problem, not a server problem.

Well, a server cannot and shouldn't be able to choose its clients, esp. because clients can't always be updated. If a client works with another server, then it's, as far as I'm concerned, server breakage. Going to do a test run with ubuntu as a server at some point just see. I don't have history with samba, so I'm not really concerned about the "bad old times" referred to in the bug report, I just want stuff to work, although I would like to know if the client is supposed to convert client's unix permissions to ACLs on the server side these days?

All in all I could have just asked in the forum whether anyone has a freenas server and

1. unix, windows, mac clients connecting to the same share via cifs/smb
2. unix permissions (chmod) working
3. timestamps working the same way they do on local fs
4. preferably also ACLs and extended attributes working

and then ask for the steps to actually accomplish that.

Coming back to the authentication issue: in samba, it seems you can list samba's view of users with

Code:

pdbedit -L

In my case, the second user that doesn't work, isn't listed. Why would that be? At which point the webgui or whatever underlying functionality it's using is supposed to create the samba users? At user creation time? At the first user specific share creation time? Can I rectify this somehow without breaking any consistencies (ie. if I create the samba user on the command-line would some freenas internals get confused)?

 

[cyberjock]

Well, I can vouch that despite it being labeled "Windows ACLs" I've definitely mounted CIFS shares on BSD, Linux, Windows, and MAC OSX. They definitely work and are definitely cross-platform. It's the protocol that matters, not the OS. So if someone is going to argue that some OS's CIFS is not working properly, then it's likely user-error or their implementation of CIFS is crap. ;)

 

[mortar]

Hello,

I'm new to freenas, and the initial steps haven't been without problems. One problem is with user authentication in samba shares:

Created two identical datasets, two users (and respective groups) and one samba share for each user. The first user can access/mount both shares (can't write to the second user's share, though), but the second user cannot access/mount any shares. Logging in through ssh works for both users. All the settings visible in the webgui appear the same for both datasets, users and shares as do the shares in smbd's config file. When the second user tries to access/authenticate a share smbd.log says NT_STATUS_ACCESS_DENIED. Tried changing the user password and rebooting the freenas server to no avail.

Is there some config file for samba which has the authentication info and/or share ownership mapping?

Right now, I'm using the latest stable release [FreeNAS-9.3-STABLE-201509022158], but initially I installed a version from May. I remember having problems with guest access to samba, but now a few upgrades later that appears to work fine.

Oh well...replying to myself, just for the record.

FreeNAS has a shell command wrapper in

Code:

/usr/local/www/freenasUI/middleware/notifier.py

The naming is rather unexpected, but from there one can see that freeNAS basically tries to use

Code:

smbpasswd -a <username>

when adding an user to create the respective samba user. Failing that, it doesn't give any error, and fail it did in my case. The comments in the code also note the omission.

The failure that smbpasswd gives when tried from the root shell for the non-working user was

Code:

Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL!

I couldn't/wouldn't care to find a reason for that command failing - the problem-solving recursion always has to stop somewhere.

However, the problem basically seems to be solved by using a different tool:

Code:

pdbedit -a -u <username>

does the trick. After that the user password can be changed from the web ui and the user authenticates to samba shares just fine.

 

[anodos]

Oh well...replying to myself, just for the record.

FreeNAS has a shell command wrapper in

Code:

/usr/local/www/freenasUI/middleware/notifier.py

The naming is rather unexpected, but from there one can see that freeNAS basically tries to use

Code:

smbpasswd -a <username>

when adding an user to create the respective samba user. Failing that, it doesn't give any error, and fail it did in my case. The comments in the code also note the omission.

The failure that smbpasswd gives when tried from the root shell for the non-working user was

Code:

Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL!

I couldn't/wouldn't care to find a reason for that command failing - the problem-solving recursion always has to stop somewhere.

However, the problem basically seems to be solved by using a different tool:

Code:

pdbedit -a -u <username>

does the trick. After that the user password can be changed from the web ui and the user authenticates to samba shares just fine.

That's interesting. I wonder whether the tdb entry was (1) not generated or (2) deleted by something you did to the user in the freenas WebGUI. I believe checking the box for the user 'disable password authentication' erases the tdb entry. I guess it's possible that unchecking it doesn't regenerate the entry. BTW, as you surmised pdbedit is the proper tool for manipulating samba's passdb.tdb file.

 

[rwfitzy]

Thanks for this, I have been having this issue with one of the users for weeks where there would be no permissions after a reboot. I always fixed with smbpasswd -a and finally today decided to find a solution. After a reboot, adding the user with smbpasswd would fail the first time and succeed the second, then a parent share access worked, but no the user home share. I have a share setup as \\Data1\data as well, which contains the user home director. After reading this post, today I did this:

Code:

[root@data1] ~# pdbedit -a -u virgo
new password:
retype new password:
Forcing Primary Group to 'Domain Users' for virgo
Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL!
Failed to add entry for user virgo.
[root@data1] ~# pdbedit -L
root:0:root
datausr:1001:DATA user
sysadm:1000:System Administrator
[root@data1] ~# pdbedit -a -u virgo
new password:
retype new password:
Forcing Primary Group to 'Domain Users' for virgo
Forcing Primary Group to 'Domain Users' for virgo
Forcing Primary Group to 'Domain Users' for virgo
Forcing Primary Group to 'Domain Users' for virgo
Unix username:        virgo
NT username:
Account Flags:        [U          ]
User SID:             S-1-5-21-1083486076-3751500825-1769682318-1001
Primary Group SID:    S-1-5-21-1083486076-3751500825-1769682318-513
Full Name:            Virgo
Home Directory:       \\data1\virgo
HomeDir Drive:
Logon Script:
Profile Path:         \\data1\virgo\profile
Domain:               DATA1
Account desc:
Workstations:
Munged dial:
Logon time:           0
Logoff time:          Sun, 04 Dec 219250468 10:30:07 EST
Kickoff time:         Sun, 04 Dec 219250468 10:30:07 EST
Password last set:    Tue, 27 Oct 2015 11:34:15 EDT
Password can change:  Tue, 27 Oct 2015 11:34:15 EDT
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
[root@data1] ~# pdbedit -L
root:0:root
virgo:1002:Virgo
datausr:1001:DATA user
sysadm:1000:System Administrator
[root@data1] ~# ls -lah /mnt/DATA/virgo
total 27
drwxrwxr-x+ 5 virgo    virgo     6B Sep 20 18:46 ./
drwxr-xr-x  6 datausr  staff     8B Sep 18 08:33 ../
-rwxrwxr-x+ 1 virgo    virgo     0B Sep 20 18:46 .windows*
drwxrwxr-x+ 4 virgo    virgo     5B Sep 19 10:07 Backup/
drwxrwxr-x+ 5 virgo    virgo    26B Oct 27 09:57 GIT/
drwxrwxr-x+ 5 virgo    virgo    25B Oct 27 10:02 Virgo/

Again, even with these commands, I am still having to do twice and not sure yet if it will survive a reboot. I can now access the parent share, but not the user home share, reports not accessible from a Windows 2008 R2 server. I'm using the parent share for now, the permissions are all proper and not allowing the user in unauthorized directories, but how can I troubleshoot the home share issue?