Samba – Access to SMB shares denied after update to FreeNAS 11.3

access-control-listsambatruenaswindows 10

My previous setup (FreeNAS 11.2) had working SMB shares with Windows 10. After an update to FreeNAS 11.3 SMB shares partially stopped working. I'd be more than thankful, if anyone could help me troubleshoot.

Any existent or newly created share on /mnt/tank/ [my files dataset] does not work, but any on /mnt/SSD/ [my jails dataset] works ok. Are there any inherited options or permissions that I can't see?

This newly created share works: [for the user joe:family]

root@server[~]# ll /mnt/SSD/share
total 9
drwx------+ 2 root  wheel  uarch 2 Apr 30 12:35 ./
drwxr-xr-x  7 root  wheel  uarch 7 Apr 30 12:35 ../

root@server[~]# getfacl /mnt/SSD/share/
# file: /mnt/SSD/share/
# owner: root
# group: wheel
     owner@:rwxpDdaARWcCos:fd-----:allow
     group:family:rwxpDdaARWcCos:fd-----:allow
     everyone@:--------------:fd-----:allow

This one, however, doesn't work:
When connecting with the user joe (by mapping a network drive in Windows 10), Windows 10 throws the error:
Windows cannot access \\server\test
You do not have permissions to access \\server\test.

root@server[~]# ll /mnt/tank/test
total 12
drwx------+  2 root  wheel  uarch  2 Apr 30 12:40 ./
drwxrwx---  14 root  wheel  uarch 14 Apr 30 12:40 ../    

root@server[~]# getfacl /mnt/tank/test
    # file: /mnt/tank/test
    # owner: root
    # group: wheel
         owner@:rwxpDdaARWcCos:fd-----:allow
         group:family:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

smbstatus shows this: The second share (test) is missing here since I can't connect to it.

root@server[~]# smbstatus

Samba version 4.10.13
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------------
46477   joe         users        192.168.178.xx (ipv4:192.168.178.xx:53566) SMB3_11           -                    partial(AES-128-CMAC)

Service      pid     Machine       Connected at                     Encryption   Signing
---------------------------------------------------------------------------------------------
share        46477   192.168.178.xx Thu Apr 30 13:38:29 2020 CEST    -            -
test         46477   192.168.178.xx Thu Apr 30 12:41:10 2020 CEST    -            -

Locked files:
Pid          User(ID)   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
46477        1001       DENY_NONE  0x100081    RDONLY     NONE             /mnt/SSD/share   .   Thu Apr 30 13:38:29 2020
46477        1001       DENY_NONE  0x100081    RDONLY     NONE             /mnt/SSD/share   .   Thu Apr 30 13:38:29 2020

Where to look next?

  1. It doesn't look like a problem with Windows 10's authentification, since the SSD-share works with the same account
  2. What is a good way to debug this problem? Which logs do I look into?
  3. Are there any problematic options inherited from the dataset? (Which commands would reveal those?) For my test I created both datasets via GUI in FreeNAS 11.3u2 and set the share type to "SMB"

Best Answer

Try reseting the password of the account you're accessing SMB with.

ntlm authentication (used by the SMB protocol in the absence of kerberos for auth), requires the server to keep an NT hash of the user's password. When a local user is added through the GUI, an NT hash of the user's password is stored in the user's entry in the freenas config file. This is then used to generate Samba's passdb.tdb file.

Prior to 11.3 FreeNAS was not very careful about making sure the configuration database and the passdb.tdb file were synchronized. This made it possible for users to try to authenticate as root over SMB, fail, use the googles, and then run "pdbedit -a root"

Doing things in this order resulted in the sqlite database not having an NT hash in it, but since 11.2 and earlier weren't validating the contents of the file things kept working.

Now fast-forward to 11.3. Starting in this version it synchronizes passbd.tdb and group_mapping.tdb on system dataset import. This means that the manually-added root account is removed from passdb.tdb. Resetting the password through the GUI causes an NT hash to be generated and stored. Root can continue to be used as your SMB account if this is your practice for the rest of the 11.3 life-cycle.

12.0 introduces a distinction between SMB users and non-SMB users (a checkbox). Only SMB users will be added to the passdb. builtin users (including root) are not permitted to be SMB users. For this reason, while you are in the 11.3 life-cycle for your FreeNAS server, it may be a good idea to transition to using a regular user account rather than root (to avoid potential issues / frustration when upgrading).

Related Topic