Update to 12.0-U3.1 broke samba shares

[Gaspetaahl]

Hello,

today I updated my Truenas Core server to 12.0-U3.1 from 12.0-U3 but after that my samba shares stopped working. My smb4.conf looks like this:

Code:

#
# SMB.CONF(5)           The configuration file for the Samba suite
# $FreeBSD$
#


[global]
        dns proxy = No
        aio max threads = 2
        max log size = 5120
        load printers = No
        printing = bsd
        disable spoolss = Yes
        dos filemode = Yes
        kernel change notify = No
        directory name cache size = 0
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        unix charset = UTF-8
        log level = 1 auth_json_audit:3@/var/log/samba4/auth_audit.log
        obey pam restrictions = False
        enable web service discovery = True
        logging = file
        server min protocol = SMB2_02
        unix extensions = No
        map to guest = Bad User
        server string = FreeNAS Server
        bind interfaces only = Yes
        netbios name = freenas
        netbios aliases =
        server role = standalone
        workgroup = WORKGROUP
        idmap config *: backend = tdb
        idmap config *: range = 90000001-100000000
        registry shares = yes
        include = registry

and the smb4_share.conf looks like this:

Code:

#
# SMB.CONF(5)           The configuration file for the Samba suite
# $FreeBSD$
#


[WG]
        path = /mnt/Volume1/WG
        read only = no
        guest ok = yes
        nfs4:chown = true
        ea support = false
        vfs objects = zfs_space zfsacl streams_xattr

[User]
        path = /mnt/Volume1/User/%U
        access based share enum = yes
        read only = no
        guest ok = no
        nfs4:chown = true
        ea support = false
        vfs objects = zfs_space zfsacl streams_xattr
        ixnas:zfs_auto_homedir = true

[User2]
        path = /mnt/Volume1/User2
        read only = no
        guest ok = no
        nfs4:chown = true
        ea support = false
        vfs objects = zfs_space zfsacl streams_xattr

[VM-Data]
        path = /mnt/Volume1/VM-Data
        browseable = no
        read only = no
        guest ok = no
        nfs4:chown = true
        ea support = false
        vfs objects = zfs_space zfsacl streams_xattr

I had a similar issue after the last update where also pdbedit -L didnt show any users. Now pdbedit -L shows all my users. Last time I could fix this with disabling and then reenabling my shares in the Truenas UI. But this time this did not work.

The error I see when using smbclient looks like this:

Code:

$ smbclient //freenas.lan/WG -u alpine
tree connect failed: NT_STATUS_BAD_NETWORK_NAME

Windows says that the security policies of my organization dont allow access.

mount -t cifs shows:

Code:

mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
mount: mounting //freenas/WG$ on /home/user/mnt/WG failed: Not supported

 

[anodos]

Run command midclt call smb.configure and see if it fixes your issue.

 

[Gaspetaahl]

It printed "275" but didn't fix the problem.

 

[anodos]

It printed "275" but didn't fix the problem.

That's a backgrounded job. You should run midclt call core.get_jobs | jq and look for that id. You're probably testing before it finishes.

 

[Gaspetaahl]

Ah, thank you for explaining. The Job finished with "SUCESS" but still the same errors.

 

[anodos]

What is output of testparm -s?

 

[Gaspetaahl]

Code:

Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

# Global parameters
[global]
        aio max threads = 2
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        enable web service discovery = Yes
        kernel change notify = No
        load printers = No
        logging = file
        map to guest = Bad User
        max log size = 5120
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        registry shares = Yes
        server role = standalone server
        server string = FreeNAS Server
        unix extensions = No
        idmap config *: range = 90000001-100000000
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[WG]
        ea support = No
        guest ok = Yes
        path = /mnt/Volume1/WG
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true


[User]
        access based share enum = Yes
        ea support = No
        path = /mnt/Volume1/User/%U
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        ixnas:zfs_auto_homedir = true
        nfs4:chown = true


[User2]
        ea support = No
        path = /mnt/Volume1/User2
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true


[VM-Data]
        browseable = No
        ea support = No
        path = /mnt/Volume1/VM-Data
        read only = No
        vfs objects = zfs_space zfsacl streams_xattr
        nfs4:chown = true

 

[anodos]

NT_STATUS_BAD_NETWORK_NAME is a very specific response. Does share path exist? Can you ping freenas.lan? Do you have different results if you use IP address?

 

[Gaspetaahl]

The share path exists and I received the same error weith IP and with hostname. I could ping it.
I tested again and now the "WG" share which is the only one with guest acces works (on Windows and Linux). However the other shares still dont work.
smbclient now says: NT_STATUS_ACCESS_DENIED

 

[anodos]

What is output of following:

Code:

getfacl /mnt/Volume1
getfacl /mnt/Volume1/User2

Assuming that's one of the shares where you're getting STATUS_ACCESS_DENIED.
Typically that NT status message indicates a permissions problem.

 

[Gaspetaahl]

So first: I just restartet my TrueNAS server to see if that chagned anything and now the "WG" share also isnt accessible anymore and smbclient shows "NT_STATUS_BAD_NETWORK_NAME" again.

getfacl /mnt/Volume1 shows:

Code:

# file: /mnt/Volume1
# owner: root
# group: wheel
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow

getfacl /mnt/Volume1/VM-Data (thats the one I tested with smbclient) shows:

Code:

# file: /mnt/Volume1/VM-Data
# owner: alpine
# group: alpine
         everyone@:------a-R-c--s:-------:deny
            owner@:rwxp--aARWcCos:-------:allow
            group@:rwxp--a-R-c--s:-------:allow
            owner@:rwxpDdaARWcCos:fdi----:allow
            group@:rwxpDdaARWcCos:fdi----:allow
         everyone@:--------------:fd-----:allow

getfacl /mnt/Volume1/User (This one also doesnt work) shows:

Code:

# file: /mnt/Volume1/User
# owner: user
# group: user
            group@:rwxpDdaARWc--s:-------:allow
         everyone@:--x---a-R-c---:-------:allow
       group:horst:rwxpDdaARWcCos:fd-----:allow
            owner@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

Now smbclient shows "NT_STATUS_BAD_NETWORK_NAME" for all shares.

 

[Gaspetaahl]

Running "midclt call smb.configure" again fixes the "WG" share. And displays "NT_STATUS_ACCESS_DENIED" for the other shares

 

[Gaspetaahl]

smbclient doesnt ask for any password. Why is that?

 

[anodos]

Does pdbedit -L show your users?

 

[Gaspetaahl]

yes

 

[anodos]

Ah, you're using the wrong `u`, you need -U <username> capital letter.

 

[Gaspetaahl]

Oh mybad. I can now access "VM-Data" with the user "alpine" using smbclient. But not with sudo mount -t cifs //freenas/VM-Data$ /home/user/mnt/VM-Data -o rw,uid=1000,gid=100,file_mode=0777,dir_mode=0777,username=alpine,password=[cesnored],_netdev,noperm,iocharset=utf8,vers=3.0,nod fs
as it displays:

Code:

mount error(95): Not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
mount: mounting //freenas/VM-Data$ on /home/user/mnt/VM-Data failed: Not supported

smbclient //freenas.lan/User -U user shows:

Code:

Enter MYGROUP\horst's password:
tree connect failed: NT_STATUS_BAD_NETWORK_NAME

 

[Gaspetaahl]

Something else that I noticed: I can access the Share "User2" when authenticating with "user" (which is what I inteded)

 

[Gaspetaahl]

I stripped ACL for alles Shares which did the trick. However this still seems like a bug with the update. I hopen this wont happen with the next update. But will report if it does.

 

[anodos]

I stripped ACL for alles Shares which did the trick. However this still seems like a bug with the update. I hopen this wont happen with the next update. But will report if it does.

The 12.0-U3 -> U3.1 update was a minimal one that mostly included a CVE fix for samba. It would not have touched your on-disk permissions.