Strange Permissions Issue w/CIFS Home Directory

[Joe Mc]

Some time ago (I'm guessing several FreeNAS updates ago), I lost the ability to write in just the -root- home directories for my users via CIFS -- I can still still navigate to sub folders beneath the home directory itself and delete or create new files, but if I attempt to delete or create a file in the main folder, I get a permissions error on the Windows client saying it needs permission from a SID number that now shows up as unknown.

Looking at the Security tab under properties, I see "Everyone", "inferno (Unix Group\inferno)" and an unknown SID. All three have a greyed-out checkbox for "Special permissions" and nothing else. I am not sure what this unknown SID is, but I spent several hours looking up related and semi-related problems on the forums all to no avail. I am also not sure if these Security properties may have looked differently when this worked fine, I have never had a need to check it.

I obtained & ran a Python script that checks for SIDs that did not get updated through a reboot, but it claimed that it had nothing to do, and that all SIDs were correct in the system. I did not manually tweak any permissions relating to home directories anytime recently, although I don't use my home directories all that often so this went un-noticed for quite some time (months).

As a side note, all NON-home directory CIFS shares are functioning perfectly normal with correct read/write permissions according to how they are set up, however they show unknown SIDs when you right-click and look at Security properties as well (again, unclear if it's always been like this).

I am not too sure what else to check/where to begin... I did some "getfacl" commands on my home directory and some of the sub directories, and they all appear to look the same (both missing d and D attributes, yet I can still delete and create files in the subfolders). UNIX permissions all seem to be in order; the username and groups have not changed since this last worked...

Any suggestions or guidance on where to begin would be greatly appreciated...

Thanks!

 

[Joe Mc]

Here's my /var/log/messages ... notice the possible deadlocks? I am running the latest version so all of the deadlock-related info I've researched here indicates those bugs have been fixed / issues resolved, so I am not too sure what's happening here...

Oct 31 04:42:24 freenas winbindd[44215]: [2015/10/31 04:42:24.374891, 0] ../lib/util/become_daemon.c:136(daemon_ready)
Oct 31 04:42:32 freenas nmbd[44207]: [2015/10/31 04:42:32.286711, 0] ../source3/nmbd/nmbd_become_dmb.c:112(become_domain_master_sta
ge2)
Oct 31 04:42:32 freenas nmbd[44207]: *****
Oct 31 04:42:32 freenas nmbd[44207]:
Oct 31 04:42:32 freenas nmbd[44207]: Samba server HDA is now a domain master browser for workgroup HADESGATE on subnet 192.168.254.4
Oct 31 04:42:32 freenas nmbd[44207]:
Oct 31 04:42:32 freenas nmbd[44207]: *****
Oct 31 04:42:47 freenas nmbd[44207]: [2015/10/31 04:42:47.306937, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
Oct 31 04:42:47 freenas nmbd[44207]: *****
Oct 31 04:42:47 freenas nmbd[44207]:
Oct 31 04:42:47 freenas nmbd[44207]: Samba name server HDA is now a local master browser for workgroup HADESGATE on subnet 192.168.254.4
Oct 31 04:42:47 freenas nmbd[44207]:
Oct 31 04:42:47 freenas nmbd[44207]: *****
Oct 31 04:51:16 freenas smbd[44647]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Oct 31 04:51:43 freenas winbindd[44216]: STATUS=daemon 'winbindd' finished starting up and ready to serve connectionssam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Oct 31 04:54:11 freenas manage.py: [common.pipesubr:71] Popen()ing: zfs list -H -o mountpoint,name
Oct 31 05:02:35 freenas winbindd[44216]: [2015/10/31 05:02:35.841563, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Oct 31 05:02:35 freenas winbindd[44216]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Oct 31 05:03:00 freenas winbindd[44216]: [2015/10/31 05:03:00.512218, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Oct 31 05:03:00 freenas winbindd[44216]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Oct 31 05:03:12 freenas winbindd[44216]: [2015/10/31 05:03:12.888632, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Oct 31 05:03:12 freenas winbindd[44216]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Oct 31 05:04:21 freenas manage.py: [common.pipesubr:71] Popen()ing: zfs list -H -o mountpoint,name
Oct 31 05:16:32 freenas winbindd[44216]: [2015/10/31 05:16:32.596377, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Oct 31 05:16:32 freenas winbindd[44216]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Oct 31 05:22:35 freenas winbindd[44216]: [2015/10/31 05:22:35.917825, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Oct 31 05:22:35 freenas winbindd[44216]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Oct 31 05:27:38 freenas manage.py: [common.pipesubr:71] Popen()ing: zfs list -H -o mountpoint,name
Oct 31 05:43:56 freenas smbd[46233]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Oct 31 05:46:06 freenas smbd[46297]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Oct 31 05:47:34 freenas smbd[46318]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Oct 31 05:48:26 freenas smbd[46341]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Oct 31 05:49:57 freenas smbd[46391]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!

 

[Joe Mc]

I think I may see an issue, or at least a significant config difference...

My structure is similar to this example::

/storage/
/storage/homes/
/storage/homes/<username1>
/storage/homes/<username2>
/storage/homes/<username3>
/storage/Share1
/storage/Share2

The permissions on storage (and thus storage/homes) is U: root G: wheel, w/755 Permission Type: Windows

However, if I look at /storage/Share1 and /storage/Share2, they are U: root G: admins w/775 Permission Type: UNIX

So, a couple questions...

1) Should I create a dataset for /storage/homes? (There currently is none, not sure if this is ill-advised? It's inheriting settings from/storage)
2) What would be the best recommended settings for user/group owners for the /homes/ directory? Could that be my entire issue?

I imagine that I could probably "fix" this by setting the group to admins, but then my non-admin group users would presumably not be able to write still... any thoughts?

 

[Joe Mc]

Update: Well, I believe I fixed my problem... but there is something weird going on still.

It turns out that I did not have a dataset for the /storage/homes, and I had a mixture of Windows and UNIX-based datasets and permissions, so I made everything Windows and now users can write to their home [root] directory. I set all the permissions in a Windows client and everything was functioning normally...

One strange thing is that, under the Windows properties (Security tab), it claims the share/folder is owned by an unknown SID. Also, for each user that is the owner, there is also another SID (separate from the SID that owns it, but also unknown) that has Full Control. I wonder if maybe this is the root, which doesn't have a Microsoft acct on FreeNAS? I noticed my other shares had an unknown SID w/full control as well, so I removed it from there... is this a bad idea that may interfere with ZFS or Samba functionality in some way?

Also, I have three users... say I am user1. if I browse to \\myserver\user1, I get my home directory w/my windows login credentials matching user1.. If I navigate to \\myserver\user2 (as long as it's any other user name that actually exists on my system, of which there are only 3), it connects and opens, but the contents are actually user1's home directory! I can read/write, but then I notice a share for user2 or even user3 showing up under Network in Windows Explorer. Is there any way to make this so users can only connect to their home directory by their name, or perhaps something generic like \\myserver\home ?

 

[Joe Mc]

Here's log output, if it's of any use. Still getting "possible deadlock" msgs as well as some new stuff sprinkled-in; "Failed to get a valid security descriptor". Hmm.

Nov 1 00:00:00 freenas newsyslog[80513]: logfile turned over due to size>100K
Nov 1 00:00:00 freenas syslog-ng[4407]: Configuration reload request received, reloading configuration;
Nov 1 02:38:09 freenas smbd[87160]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Nov 1 02:39:03 freenas winbindd[71175]: [2015/11/01 02:39:03.279013, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Nov 1 02:39:03 freenas winbindd[71175]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Nov 1 02:50:37 freenas smbd[87533]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Nov 1 03:11:15 freenas notifier: Performing sanity check on sshd configuration.
Nov 1 03:16:55 freenas winbindd[71175]: [2015/11/01 03:16:55.683758, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Nov 1 03:16:55 freenas winbindd[71175]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Nov 1 03:19:34 freenas smbd[89497]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Nov 1 03:32:42 freenas winbindd[71175]: [2015/11/01 03:32:42.223844, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Nov 1 03:32:42 freenas winbindd[71175]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190
Nov 1 03:34:44 freenas smbd[89497]: [2015/11/01 03:34:44.842390, 0] ../source3/rpc_server/svcctl/srv_svcctl_nt.c:326(_svcctl_OpenServiceW)
Nov 1 03:35:06 freenas smbd[89497]: _svcctl_OpenServiceW: Failed to get a valid security descriptor_svcctl_OpenServiceW: Failed to get a valid security descriptor_svcctl_OpenServiceW: Failed to get a valid security descriptorFailed to fetch record!
Nov 1 03:35:22 freenas smbd[89497]: [2015/11/01 03:35:22.251108, 0] ../source3/rpc_server/svcctl/srv_svcctl_nt.c:326(_svcctl_OpenServiceW)
Nov 1 03:37:46 freenas smbd[90230]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Nov 1 03:38:00 freenas smbd[89497]: _svcctl_OpenServiceW: Failed to get a valid security descriptorjoe-desktop (ipv4:192.168.254.139:56184) closed connection to service Backup
Nov 1 03:39:21 freenas smbd[90272]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to fetch record!
Nov 1 03:39:30 freenas winbindd[71175]: [2015/11/01 03:39:30.385723, 0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
Nov 1 03:39:30 freenas winbindd[71175]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2203416046-1344373031-3839389190

 

[Joe Mc]

Another update... I think all of my issues are resolved, but it sure was confusing.

In order to address and resolve the SID translation discrepancy, I figured I would try re-creating my users. When I deleted and re-created the first user, I used the same UID (1001). At that point, I could no longer authenticate through CIFS/smb, even though I could SSH into the FreeNAS OS just fine. If I ran "net usersidlist", the username I re-created would show up without any SIDs below it. I then rebooted the FreeNAS machine, and at that point the user that I re-created would not show up at all and I would get Access Denied any time I tried to access my home directory as that user.

I then deleted the username and re-created it using a new UID (non-1001), and that seems to have resolved everything including the deadlock errors in the logs. Also, when I look at the owner and permissions in Windows, it resolves properly and everything seems happy. I guess I will just rebuild the other users that have these issues then I should be set... there is obviously some sort of background script or clean-up process not being done when using the GUI to remove a UID, however... I suppose I'll chalk it up to some of the FreeNAS/Samba4 bugs I've seen referenced there were similar but not identical problems to mine? Not sure.

tl;dr - Rebuilt users using fresh UIDs and it seems to have resolved everything.

PS: I also learned that authenticating as any user on the system to access a home directory is apparently normal Samba behavior... Odd.

 

[anodos]

Another update... I think all of my issues are resolved, but it sure was confusing.

In order to address and resolve the SID translation discrepancy, I figured I would try re-creating my users. When I deleted and re-created the first user, I used the same UID (1001). At that point, I could no longer authenticate through CIFS/smb, even though I could SSH into the FreeNAS OS just fine. If I ran "net usersidlist", the username I re-created would show up without any SIDs below it. I then rebooted the FreeNAS machine, and at that point the user that I re-created would not show up at all and I would get Access Denied any time I tried to access my home directory as that user.

I then deleted the username and re-created it using a new UID (non-1001), and that seems to have resolved everything including the deadlock errors in the logs. Also, when I look at the owner and permissions in Windows, it resolves properly and everything seems happy. I guess I will just rebuild the other users that have these issues then I should be set... there is obviously some sort of background script or clean-up process not being done when using the GUI to remove a UID, however... I suppose I'll chalk it up to some of the FreeNAS/Samba4 bugs I've seen referenced there were similar but not identical problems to mine? Not sure.

tl;dr - Rebuilt users using fresh UIDs and it seems to have resolved everything.

PS: I also learned that authenticating as any user on the system to access a home directory is apparently normal Samba behavior... Odd.

The permissions issues you mentioned are often result from having cifs share set with 'unix' permissions type. It sounds like there are still some bugs in the scripts handling sid /idmap. Glad you found a workaround.