When are SMB permissions going to be fixed?

[jayecin]

This is getting ridiculous how broken SMB shares have been since upgrading from FreeNAS to TrueNAS. I am constantly having issues with permissions just flat out not working or when I map a drive it opens another share by a completely different name or a drive with the same name as the user. For example I created a new local user on TrueNAS, username is "backup" and its sole purpose was to have access to an SMB share called "/mnt/storage/backup". I made the account yesterday and after initially setting it up the permissions didnt work. I got the standard windows BS about not having permission to access the drive. Verified the share permissions, verified the user "backup" had full privilege to the "/mnt/storage/backup" share, messed around with removing the settings, re adding the setting, deleting the account re adding the account and then finally it just randomly worked. I rebooted the windows server that was being used to access the "/mnt/storage/backup" by the "backup" user and now suddenly the account "backup" no longer has access to the "/mnt/storage/backup" SMB share. These issues only started when I migrated from FreeNAS 11.3 to TrueNAS. Prior to the upgrade my permissions all worked properly with no issues. I have tried deleting the shares in the past and remaking them, that fixed nothing. I have deleted all the ACLs, re-added them with no effect, deleted users and re-added them with no effect. I believe I found another issue where if a SMB file share is the same name as a user account, that user account will automatically use that SMB share as its private or "homes" folder. So when I just navigate to \\TrueNASIP\ authenticated as the "backup" user I see a folder called "homes". I dont have any shares on my TrueNAS called "homes" for user shares I was using "/mnt/storage/private/<username>", the "backup" users "homes" folder maps to "/mnt/storage/backup" even though in the user settings I have the "homes" or private share located at "/mnt/storage/private/backup" This is really becoming a problem for me and I am considering dumping TrueNAS and moving to another solution.

 

[Kris Moore]

@jayecin - Is this related to a specific bug that's been reported? If so, a whole slew of those fixes are slated to ship next Tuesday with 12.0-U2.

 

[jayecin]

Im not sure I havent looked through the up coming release notes. Another thing I noticed is that shares tend to work a lot better for SMB when the windows account matches the TrueNAS account. So i remember that yesterday while troubleshooting, once i changed the windows account on the computer I was using to access "/mnt/storage/backup" to use the username "backup" with the same password as the account on TrueNAS, thats when it started working, until today. I had noticed that behavior in the past as well and yes I make sure I use different credentials when mapping the drive, so its not an issue of me not changing the authentication used to map the drive on the windows share.

 

[anodos]

This is getting ridiculous how broken SMB shares have been since upgrading from FreeNAS to TrueNAS. I am constantly having issues with permissions just flat out not working or when I map a drive it opens another share by a completely different name or a drive with the same name as the user. For example I created a new local user on TrueNAS, username is "backup" and its sole purpose was to have access to an SMB share called "/mnt/storage/backup". I made the account yesterday and after initially setting it up the permissions didnt work. I got the standard windows BS about not having permission to access the drive. Verified the share permissions, verified the user "backup" had full privilege to the "/mnt/storage/backup" share, messed around with removing the settings, re adding the setting, deleting the account re adding the account and then finally it just randomly worked. I rebooted the windows server that was being used to access the "/mnt/storage/backup" by the "backup" user and now suddenly the account "backup" no longer has access to the "/mnt/storage/backup" SMB share. These issues only started when I migrated from FreeNAS 11.3 to TrueNAS. Prior to the upgrade my permissions all worked properly with no issues. I have tried deleting the shares in the past and remaking them, that fixed nothing. I have deleted all the ACLs, re-added them with no effect, deleted users and re-added them with no effect. I believe I found another issue where if a SMB file share is the same name as a user account, that user account will automatically use that SMB share as its private or "homes" folder. So when I just navigate to \\TrueNASIP\ authenticated as the "backup" user I see a folder called "homes". I dont have any shares on my TrueNAS called "homes" for user shares I was using "/mnt/storage/private/<username>", the "backup" users "homes" folder maps to "/mnt/storage/backup" even though in the user settings I have the "homes" or private share located at "/mnt/storage/private/backup" This is really becoming a problem for me and I am considering dumping TrueNAS and moving to another solution.

Can you provide the version of TrueNAS you're running as well as the output of testparm -s

 

[jayecin]

Version:
TrueNAS-12.0-U1.1

root@XXX[~]# testparm -s
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 = 51200
nsupdate command = /usr/local/bin/samba-nsupdate -g
obey pam restrictions = Yes
registry shares = Yes
restrict anonymous = 2
server role = standalone server
server string = FreeNAS Server
unix extensions = No
username map = /usr/local/etc/smbusername.map
username map cache time = 60
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
directory name cache size = 0
dos filemode = Yes


[software]
ea support = No
kernel share modes = No
path = /mnt/storage/software
posix locking = No
read only = No
vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
nfs4:chown = true


[backup]
ea support = No
kernel share modes = No
path = /mnt/storage/backup
posix locking = No
read only = No
vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
nfs4:chown = true


[photos]
ea support = No
kernel share modes = No
path = /mnt/storage/photos
posix locking = No
read only = No
vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
nfs4:chown = true


[homes]
ea support = No
kernel share modes = No
path = /mnt/storage/private/%U
posix locking = No
read only = No
vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
nfs4:chown = true


[camera]
ea support = No
kernel share modes = No
path = /mnt/storage/camera
posix locking = No
read only = No
vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
nfs4:chown = true


[media]
ea support = No
kernel share modes = No
path = /mnt/storage/media
posix locking = No
read only = No
vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
nfs4:chown = true

 

[anodos]

Okay. So you have a [homes] share. It's browsable, that's why you somethings see "homes" in your share list (as well as a share with your user's name). This is how a home share works.

There was an extremely old bug in samba registry shares that I fixed for U1 that interpreted share names out of order in the case. Samba should have been looking up share names for non-home shares before switching to checking for username / home directories. SERVER\backup should have brought you to /mnt/storage/backup, but instead would result in /mnt/storage/private/backup (which may not exist) and therefore results in failure to mount share. Ditto for `media`. I fixed this bug upstream here: https://gitlab.com/samba-team/devel/samba/-/commit/7b52c2db264a92ea77bcb7e45e016ea03f699393

I have seen a couple of cases recently where Windows clients seem to "forget" the credentials they have been using to authenticate to remote shares (different creds being passed over the wire). You can see what user account is being sent by running the command midclt call smb.status AUTH_LOG | jq and maybe verify that it is the correct one. If you can reliably reproduce a permissions issue, I am keen to fix it, but I need exact steps to reproduce the issue or access to your server.

 

[jayecin]

Thanks for the quick response.

I remember the bug that you mentioned about share names out of order, i had that bug as well, which maybe clouding my perception of this new bug.

So for the homes shares that makes sense that it does exist, what doesnt make sense is that for the user "backup" the homes share is "/mnt/storage/backup". On my windows server that i use the backup account for, I have to mount the drive as "\\<TrueNASIP>\homes" which actually maps to "/mnt/storage/backup". If i try to map a drive to "\\<TrueNASIP>\backup" i get a permission errors. I just discovered this today.

this floods the screen when I run the command

midclt call smb.status AUTH_LOG | jq

{
"timestamp": "2021-01-29T13:54:14.484638-0500",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4624,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_OK",
"localAddress": "ipv4:xx.xx.xx.xx:445",
"remoteAddress": "ipv4:xx.xx.xx.xx:58981",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "",
"clientAccount": "",
"workstation": "BACKUP",
"becameAccount": "nobody",
"becameDomain": "VM1",
"becameSid": "S-1-5-21-1255358638-2626539550-1903512230-501",
"mappedAccount": "",
"mappedDomain": "",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": null,
"duration": 3689
}
},

 

[anodos]

Interesting looks like client is trying to perform a guest session. midclt call smb.status AUTH_LOG '[["Authentication.status", "!=", "NT_STATUS_OK"]]' | jq should show auth failures. This generally works better in an SSH session BTW (where you can easily scroll up ).

 

[Samuel Tai]

@jayecin, you may also be hitting a client-side restriction. See https://docs.microsoft.com/en-us/tr...g/guest-access-in-smb2-is-disabled-by-default. This may also be a factor in these access issues.

 

[anodos]

A simple way to isolate whether it's a client issue is to attempt to connect locally through the smbclient utility smbclient //127.0.0.1/backup -U backup.

 

[jayecin]

So i did just confirm that the backup name thing appears to be a bug. If a username matches the folder of an smb share, that user will use the smb share as its homes directory. Not sure of more than that or how exactly its working that way.

With the username "backup" the "homes" directory is actually not the homes directory of "/mnt/storage/private/backup" set in the user account, but maps to "/mnt/storage/backup". To verify this I created a second account of "backup1" and gave it identical permissions as "backup". Then i attempted to mount the drive "/mnt/storage/backup" with the user "backup1" and it worked properly and as expected. I then dismounted the drive and cleared all the authentications with "net use" command and attempted to remount the drive using the "backup" credentials and it worked fine this time... however prior this, all day every time I tried to mount a drive to "/mnt/storage/backup" using the "backup" account I would get a permission denied. The only way I could access the "/mnt/storage/backup" using the "backup" credentials is if i actually mounted it as "mnt/homes" then when i opened the drive it would show me the share "/mnt/storage/backup".

So i cant reliably reproduce it, but at least I understand my problem now.

 

[anodos]

Okay. My memory was a bit fuzzy about the situation (slept since then). 12.0-RELEASE issue was user access attempts to a share that's identical to a username (but not that user's name) results in attempt to mount other user's homedir. There's a "media" user with home directory "/mnt/dozer/homes/media" and a regular share named "media" at "/mnt/dozer/media". Bob tries to mount \\server\media, and Samba tried to interpret as access attempt to "/mnt/dozer/homes/media", fails and returns ACCESS_DENIED. This is clearly wrong and was fixed.

The case of "media" user trying to access \\server\media is somewhat trickier. You can only access one of the two shares with the same name. "media" user gets dumped in his home directory. This one can go both ways (some may want the home share, others may want the regular share). Better practice is to avoid using shares with names that are the same as usernames if you're using [homes].

 

[jayecin]

Thanks for the help, I will make sure that usernames do not match folder names going forward.