SMB broken after upgrade to 12.0-U6

[merch24]

Hello,

I can't understand why there is permanently messed things up with SMBs after upgrades. It cost me half a day already with no clue what the matter is.
Situation :
I normally have SMB mounts from TrueNAS to Windows, these SMB mounts are mounted as network shares and are also shared with several VMs (VMWare Workstation Pro). This was working like a charm until I upgraded today in the morning.

The SMB mounts in Windows are still there, but something is different, as I cannot access the directories in my VMs anymore. If you mount them with allow_other (normally done via fstab) they have simply no permissions at all anymore in the guests, it looks like this then
d---------. 1 root root 0 Oct 14 10:43 Cinema_I
You can also mount them with uid, gid, umask, that all does not help the slightest. Even if you do

Code:

[root@localhost mnt]# /usr/bin/vmhgfs-fuse .host:Cinema_I /mnt/Cinema_I -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000,umask=007
[root@localhost mnt]# ll /mnt
total 0
drwxrwx---. 1 tg   tg   0 Oct 14 10:43 Cinema_I
[root@localhost mnt]# cd /mnt/Cinema_I/
-bash: cd: /mnt/Cinema_I/: Permission denied
[root@localhost mnt]# 

What I did :
Completely remap the ACLs in TrueNAS
Completely disconnected shares in Windows, even deleted the credentials from credential manager, completely reconnected shares in Windows
Completely removed the shares from VMs and reapplied them
Set up several new VMs with several different versions of fuse and open-vm-tools (Fedora, Alma), and set up the shared folders from scratch

It all leads to exactly the same issue, the folders are not accessible anymore
This drives me literally crazy, but it all comes down to the upgrade because all else was checked as you can see above, there is nothing to get that working. There were no updates to VMWare done, it is the same version since more than half a year. New guest installs were completely from scratch
So it would be nice if someone could tell me what exactly you did to SMB and how to fix that issue for U6 because I am not able to do my work anymore

Many thanks

 

[merch24]

What I did not do was to mount a local drive as share to one of the VMs, but as expected this still works without any issues. In the meanwhile I also booted back to 12.0 U5.1, but the functionality is still completely broken

 

[anodos]

What version did you upgrade from? What is output of `testparm -s`?

 

[merch24]

my last reply was not approved until now, it was 12.0 U5.1, as the other boot entries I have were only default and initial-install

this the output in the rebooted old version :

Code:

[Cinema_I]
        access based share enum = Yes
        browseable = No
        comment = Movies and TV Shows Share I
        ea support = No
        kernel share modes = No
        path = /mnt/Media_I/Cinema_I
        posix locking = No
        read only = No
        vfs objects = streams_xattr shadow_copy_zfs ixnas crossrename recycle aio_fbsd
        crossrename:sizelimit = 10000
        recycle:subdir_mode = 0700
        recycle:directory_mode = 0777
        recycle:touch = yes
        recycle:versions = yes
        recycle:keeptree = yes
        recycle:repository = .recycle/%U
        nfs4:chown = true

and this from the U6 version, sorry I forgot the global part in the rebooted one

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
        max log size = 5120
        netbios name = TRUENAS
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        registry shares = Yes
        restrict anonymous = 2
        server role = standalone server
        server string = TrueNAS Server
        unix extensions = No
        idmap config *: range = 90000001-100000000
        idmap config * : backend = tdb
        directory name cache size = 0
        dos filemode = Yes


[Cinema_I]
        access based share enum = Yes
        browseable = No
        comment = Movies and TV Shows Share I
        ea support = No
        kernel share modes = No
        path = /mnt/Media_I/Cinema_I
        posix locking = No
        read only = No
        vfs objects = streams_xattr shadow_copy_zfs ixnas crossrename recycle aio_fbsd
        crossrename:sizelimit = 10000
        recycle:subdir_mode = 0700
        recycle:directory_mode = 0777
        recycle:touch = yes
        recycle:versions = yes
        recycle:keeptree = yes
        recycle:repository = .recycle/%U
        nfs4:chown = true

There is no difference in that. But there has to be something different now how Windows sees the shares from TrueNAS because as said in previous post, a local hard drive works as VM share without issues, and if you debug vmhgfs-fuse you also clearly see that there is access restricted. But in Windows nothing is restricted, you can access it normally.

Code:

[root@fedora ~]# /usr/bin/vmhgfs-fuse .host:/Cinema_II /mnt/test -d -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000

[tg@fedora mnt]$ ll
total 0
d---------. 1 tg   tg   0 Oct 14 11:00 test

[tg@fedora mnt]$ cd test
bash: cd: test: Permission denied

access / 01
   unique: 10, error: -13 (Permission denied), outsize: 16
unique: 12, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 2347
access / 01
   unique: 12, error: -13 (Permission denied), outsize: 16

...............................

[root@fedora ~]# /usr/bin/vmhgfs-fuse .host:/Cinema_II /mnt/test -d -o subtype=vmhgfs-fuse,allow_other,uid=1000,gid=1000,umask=000

[tg@fedora mnt]$ ll
total 0
drwxrwxrwx. 1 tg   tg   0 Oct 14 11:00 test

[tg@fedora mnt]$ cd test
bash: cd: test: Permission denied

access / 01
   unique: 6, error: -13 (Permission denied), outsize: 16
unique: 8, opcode: ACCESS (34), nodeid: 1, insize: 48, pid: 2347
access / 01
   unique: 8, error: -13 (Permission denied), outsize: 16

 

[merch24]

The culprit seems to lie in how the VMs "see" the windows shares now in terms of permissions as opposed to local drives AND before the upgrade

 

[anodos]

The culprit seems to lie in how the VMs "see" the windows shares now in terms of permissions as opposed to local drives AND before the upgrade

ACL-related code wasn't changed between U5.1 and U6. Use `smbstatus` to verify that your Windows client has authenticated as the expected user. Also check output of midclt call smb.status AUTH_LOG | jq to check historic auth attempts. If you see name of your windows client followed by $ it might mean that access is being attempted as the local (on Windows) system account, which will fail of course.


What is ACL on /mnt/Media_I/Cinema_I? (getfacl)

 

[merch24]

But it has nothing to do with failed Windows system account, as I told you. Windows has no access problems, the VMs that want to access the Windows shares cannot do this anymore since today, from absolutely nowhere. It has something to do with the permissions the shares have in Windows, and what is passed on to the VMs. There cannot be another reason. There are no auth attempts of Windows client machine followed by $

Another point to prove that is that in the meanwhile I tried to connect via cifs mount directly from the VMs to the NAS, and this works without any issues, too.

Code:

root@tgtn[~]# smbstatus

Samba version 4.12.15
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------------
1596    tg           tg           <Windows_IP> (ipv4:<Windows_IP>:8250)       SMB3_11           -                    partial(AES-128-CMAC)

Service      pid     Machine       Connected at                     Encryption   Signing
---------------------------------------------------------------------------------------------
Cinema_II    1596    <Windows_IP>   Thu Oct 14 15:19:56 2021 CEST    -            -
Storage_II   1596    <Windows_IP>   Thu Oct 14 15:19:56 2021 CEST    -            -
Cinema_I     1596    <Windows_IP>   Thu Oct 14 15:19:56 2021 CEST    -            -
Torrent      1596    <Windows_IP>   Thu Oct 14 15:19:56 2021 CEST    -            -
Storage_III  1596    <Windows_IP>   Thu Oct 14 15:19:56 2021 CEST    -            -
Locked files:
Pid          User(ID)   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
1596         1001       DENY_NONE  0x100180    RDONLY     NONE             /mnt/Media_I/Cinema_I   .   Thu Oct 14 16:53:05 2021
1596         1001       DENY_NONE  0x100081    RDONLY     NONE             /mnt/Media_I/Cinema_I   .   Thu Oct 14 16:06:06 2021
1596         1001       DENY_NONE  0x100180    RDONLY     NONE             /mnt/Storage_I/Cinema_II   .   Thu Oct 14 16:53:05 2021
1596         1001       DENY_NONE  0x100180    RDONLY     NONE             /mnt/Storage_III/Storage_III   .   Thu Oct 14 16:51:14 2021
1596         1001       DENY_NONE  0x100180    RDONLY     NONE             /mnt/Storage_I/Torrent   .   Thu Oct 14 16:52:55 2021
1596         1001       DENY_NONE  0x100180    RDONLY     NONE             /mnt/Storage_II/Storage_II   .   Thu Oct 14 16:38:21 2021
1596         1001       DENY_NONE  0x100081    RDONLY     NONE             /mnt/Storage_I/Cinema_II   Mediahandler   Thu Oct 14 15:53:15 2021

root@tgtn[~]# getfacl /mnt/Media_I/Cinema_I
# file: /mnt/Media_I/Cinema_I
# owner: tg
# group: media
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:--------------:fd-----:allow

 

[anodos]

Well, you can verify that the ACLs returned for your SMB share are same between two versions. In powershell on Windows ` Get-ACL <path> | format-list`.
Without looking into details of your server, it's also possible in some complex configurations for system dataset setup to get broken causing SMB to not be fully configured `midclt call smb.configure -job`

 

[merch24]

Well, honestly I do not know what it is. I leave it be, like so many things should better be left in IT nowadays :D
Windows works and I connect directly via Samba/Cifs now from my VMs, this seems to do the job.
Would have been nice to know the reason but I absolutely hate Windows, I am a Unix/Linux guy so I do not have enough knowledge on deeper Windows things to debug that. The thing is it is something in Windows itself, the Connection Windows<->NAS is ok, the Connection VM<->NAS is ok, the connection NAS<->Windows<->VM was ok but is not anymore (just for the NAS)

After calling midclt call smb.configure -job now all my network drives are gone and I cannot even reconnect