SMB previously working fine, now gets access denied

neopolitan6

Dabbler
Joined
Sep 18, 2018
Messages
13
Summary: I can't figure out what changed that my smb shares used to work fine, but today I get access denied.

I have various datasets and smb shares, mostly set up like this:

user "myuser" with group "myusergroup"
datasets: Media, MyFiles, BusinessFiles, NVR-Recordings
permissions for each dataset above: owner "nobody" group is "myusergroup" **more on this later
smb share for each desired dataset: Media, MyFiles, BusinessFiles, NVR-Recordings
*note: no one actually connects to the smb shares anymore except me, and some ubuntu servers noted below*

This was working fine until today. I had a Ubuntu server mounting an smb share for the NVR-Recordings, and another Ubuntu VM using Plex mounting the smb share for Media. I have a nextcloud plugin jail directly mounting BusinessFiles via a jail mount point.

As is my weekly custom, on Wednesdays I login to each Ubuntu machine and run apt update/upgrade. I went to FreeNAS plugin page and tried Update, got an error that file already exists.
Code:
[Errno 17] File exists: '../var/run/log' - > '/mnt/iocage/jails/nextcloud/root/dev/log'


I think, no worries just move on.

Well, later I noticed that nextcloud was not synced, and the web page for the nextcloud install gives an error.

After some rudimentary troubleshooting (my FreeNAS skills are beginner/low intermediate), I found that ALL my datasets now have root:wheel for ownership. I cannot recall exactly how I left them all, but definitely not that.

This seems easy to fix -- just go in and adjust the dataset ownership back to nobody:myusergroup. But it doesn't work. I tried making it recursive. myuser:myusergroup doesn't work either.

To make matters even more confusing for me, the NVR had lost access to the smb share; but now has it back. Nothing else works as it had yesterday (or this morning).

Where can I look now?
 

neopolitan6

Dabbler
Joined
Sep 18, 2018
Messages
13
Oh, a brand new dataset with nobody:myusergroup and an smb share works fine.

And a new user "myuser1" added to "myusergroup" does not work.
 

neopolitan6

Dabbler
Joined
Sep 18, 2018
Messages
13
I just found: this post that says that if a user wants access to /mnt/tank/dataset1 that user must have access to /mnt/tank also. I made one more change and put my equivalent to /mnt/tank permissions to nobody:myusergroup, and things appear better. Plex works, and my local computer can browse the smb shares.

Two final questions:
- Why would permissions change like that on my datasets (the only things I did today before trouble started were clicking update on 2 plugins)
- is my permissions solution good, or are there suggestions I really should consider?

(small business backups + family use storage and media)
 

notspam

Dabbler
Joined
Nov 10, 2019
Messages
26
I have the same problem after upgrading from 11.2-U3 to 11.2-U6 today. None of my SMB shares work. What did the upgrade change that would affect this?
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
Is it (1)you have the same problem (your permissions changed) or (2) you have the same problem (you can't access your SMB shares)?

In the case of (1), permissions reset can happen if "apply default permissions" is checked when creating an SMB share. If a user inadvertently shares out the wrong dataset, it can result in large-scale unintended permissions changes. With the ACL manager in 11.3, this should be easier to spot and remedy.

In the case of the (2) there are various reasons why SMB shares may stop working, but I have yet to see a case where it's directly caused by an upgrade in a properly-configured system. You can start to diagnose this problem by first determining whether the SMB server is actually starting. You can do this by typing in the shell "service samba_server status". Samba has three components (smbd - the SMB server, nmbd - the NetBIOS name server, and winbindd - domain join and idmapping). All three should be running. If none are running, type the command "smbd -i -d 3". If you see an error message, copy it out and create a new ticket. If it doesn't generate an error message, hit ^c (control+c) to kill the interactive session and then restart from the service GUI. If you set the auxiliary parameter "log level =1 auth_audit:5" under services->SMB, you can "tail -f /var/log/samba4/log.smbd" to watch in-progress SMB authentication and authorization. This will let you know what user you're authenticating as and whether the client is getting rejected by the server. If you see nothing in the log during connection attempts, then you probably have networking problems.

If samba starts normally and you see failed login attempts, then it's probably some sort of permissions issue. You can use "getfacl" to read the ACL on a file. If your share is /mnt/tank/share, then you should check output of "getfacl /mnt/tank" and "getfacl /mnt/tank/share". In this example your user _must_ have execute (x) permissions on /mnt/tank. The majority of permissions issues I've seen on the forums directly result from stripping (x) from other on this path (i.e. chmod 770 /mnt/tank).
 

neopolitan6

Dabbler
Joined
Sep 18, 2018
Messages
13
In my case it was not an SMB issue. The real issue is the permissions got changed. I did not create new SMB shares; as suggested above. Unless I did something a while ago, starting a latent change that didn't get expressed until last Wednesday. But I'm at a loss as to how to track that down.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
In my case it was not an SMB issue. The real issue is the permissions got changed. I did not create new SMB shares; as suggested above. Unless I did something a while ago, starting a latent change that didn't get expressed until last Wednesday. But I'm at a loss as to how to track that down.
11.3 will make it somewhat easier to track this down by using "midclt call core.get_jobs | jq", which will show completed jobs (including permissions changes). The 11.3 ACL and permissions manager is also much safer in this regard than 11.2 permissions (by default recursive jobs will not reach beyond the dataset that you're changing). In 11.2-U6, the same midclt command will show permissions resets caused by SMB share changes, but not ones triggered by permissions changes via GUI permissions manager. You can PM me a debug and I might see something indicating why permissions changed, but some collateral can be lost if you don't catch it immediately.
 

neopolitan6

Dabbler
Joined
Sep 18, 2018
Messages
13
Thanks for the reply. Seeing it's up and running now, and I know to check permissions if this happens again, I think I'll call it good for now.

I've done the midclt call, saved the results. I don't know how long it goes back (btw, how to decode the date? it's a 13 digit number), and I did a lot of permissions changes trying to figure out the issue. I think the real problem is buried too far back.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
I've done the midclt call, saved the results. I don't know how long it goes back (btw, how to decode the date? it's a 13 digit number)
You can use "date -r" to convert the unix timestamp to human-readable form:
Code:
root@freenas[/mnt/Z/src/middlewared]# date -r 1573465787318
Wed Feb 23 05:48:38 PST 51831
 

notspam

Dabbler
Joined
Nov 10, 2019
Messages
26
Is it (1)you have the same problem (your permissions changed) or (2) you have the same problem (you can't access your SMB shares)?

In the case of (1), permissions reset can happen if "apply default permissions" is checked when creating an SMB share. If a user inadvertently shares out the wrong dataset, it can result in large-scale unintended permissions changes. With the ACL manager in 11.3, this should be easier to spot and remedy.

In the case of the (2) there are various reasons why SMB shares may stop working, but I have yet to see a case where it's directly caused by an upgrade in a properly-configured system. You can start to diagnose this problem by first determining whether the SMB server is actually starting. You can do this by typing in the shell "service samba_server status". Samba has three components (smbd - the SMB server, nmbd - the NetBIOS name server, and winbindd - domain join and idmapping). All three should be running. If none are running, type the command "smbd -i -d 3". If you see an error message, copy it out and create a new ticket. If it doesn't generate an error message, hit ^c (control+c) to kill the interactive session and then restart from the service GUI. If you set the auxiliary parameter "log level =1 auth_audit:5" under services->SMB, you can "tail -f /var/log/samba4/log.smbd" to watch in-progress SMB authentication and authorization. This will let you know what user you're authenticating as and whether the client is getting rejected by the server. If you see nothing in the log during connection attempts, then you probably have networking problems.

If samba starts normally and you see failed login attempts, then it's probably some sort of permissions issue. You can use "getfacl" to read the ACL on a file. If your share is /mnt/tank/share, then you should check output of "getfacl /mnt/tank" and "getfacl /mnt/tank/share". In this example your user _must_ have execute (x) permissions on /mnt/tank. The majority of permissions issues I've seen on the forums directly result from stripping (x) from other on this path (i.e. chmod 770 /mnt/tank).

After digging further, I found that chown -R the data sets to something besides root:wheel gave me enough access to reapply all the permissions from Windows. It looks like I was using a non-supported way of SMB share setup by using the guest maybe. The upgrade took that away and reset a bunch of stuff. I still need to reset some other of my home systems to access with renewed credentials. Now I am trying to get NextCloud back up and running.
 
Top