6.10.0-RC4 Permissions Issues

[CAMPxASSASSIN]

Hello. I think this may be a bug but I'm not seeing any other posts about it. I wanted to check if this is a issue with a known solution. I updated my server to 6.10.0-RC4 to be able to run a Windows 11 VM. I noticed that after the update I could no longer access any shares that have NTFS permissions applied to them. When Accessing a share I would get an error saying I do not have permissions. My server is set up in a Active Directory domain that is used for accounts and permissions. I checked all the permissions, DNS resolution, left and rejoined the domain, and rebooted the DC and clients but it did not help. I have reverted back to 6.9.2 and all is working as intended. Has anyone else had this happen?

[Sam A]

I have a similar set up to you.  Running 6.9.2, Domain Joined Unraid server.

Works great on 6.9.2.. Upgraded to 6.10.2 and lost access to shares.  Folder/File permissions looked correct, and testing from a Windows machine, the effective permissions were correct.  That said, I could not access the share from a linux server or some a windows machines that wasn't logged in as a domain administrator.

None of my troubleshooting worked.  I ended up reverting back to 6.9.2 as well...

I tried leaving the domain (which wouldn't leave); so I reverted the settings back to Workgroup setting for SMB, rebooted.. Then tried to join the domain again, join was successful; but permission was still not working on the share.

[Clevernickname]

I found this post while searching for solutions.  After messing around a bit, this worked for me.  Took a long time however.

 

WARN - this could really mess up your file permissions.  This worked for me, but might not work for you.

 

1) Use WinSCP to reset permissions on your shares and all files in those shares to your Domain Administrator account.   If the domain/user don't show up in WinSCP, it probably means unraid isn't connected.  It might also mean that you changed the default owner in the settings to something else.

 

WinSCP has a checkbox to apply to children; you'll need to check that checkbox.

 

2) You should then be able to use your domain admin account on a windows box to set the correct owners for the files/directories.  I use groups.  One for read access (groupname-R) and one for write access (groupname-RW).  I also leave the administrator account as full access; otherwise, I won't be able to change permissions using that account.

 

While #1 is pretty quick, #2 was really slow for me.  I'm all done now, but I've been working through this for a couple of hours.

 

I have no idea why all of the permissions where lost after upgrading; my groups where still assigned, but the files where owned by something else.

 

 

Edited June 2, 2022 by Clevernickname

[Sam A]

On 6/1/2022 at 10:14 PM, Clevernickname said:

I found this post while searching for solutions.  After messing around a bit, this worked for me.  Took a long time however.

 

WARN - this could really mess up your file permissions.  This worked for me, but might not work for you.

 

1) Use WinSCP to reset permissions on your shares and all files in those shares to your Domain Administrator account.   If the domain/user don't show up in WinSCP, it probably means unraid isn't connected.  It might also mean that you changed the default owner in the settings to something else.

 

WinSCP has a checkbox to apply to children; you'll need to check that checkbox.

 

2) You should then be able to use your domain admin account on a windows box to set the correct owners for the files/directories.  I use groups.  One for read access (groupname-R) and one for write access (groupname-RW).  I also leave the administrator account as full access; otherwise, I won't be able to change permissions using that account.

 

While #1 is pretty quick, #2 was really slow for me.  I'm all done now, but I've been working through this for a couple of hours.

 

I have no idea why all of the permissions where lost after upgrading; my groups where still assigned, but the files where owned by something else.

 

 

 

I have a very similar set up to you @Clevernickname.... AD Initial owner: Administrator; AD initial group is Domain Admins; then I manage the permissions based on group membership; which was added by a Windows machine.  Permission like this is on the files/metadata.  I'm surprised that rewriting the permissions resolved the issue. Also, if feel like my issue was more around share permissions; not so much file permissions..  I could test the affective permissions from my domain admins account; effective permissions were good... But testing with the impacted account couldn't even access the root of the server e.g. \\<hostname>\ ; as well as the \\<hostname>\<shareName>\ ... I don't understand Unraid well enough to know if they somehow apply the same share permissions as the file permissions?  Maybe; In windows they're treated differently/independent of one another. 
I'll give that a shot after a couple more .releases.    

Hopefully they identify the issue and resolve it, or have a very clear work-around documented... Seems like a defect/bug. 

 

 

Edited June 6, 2022 by Sam A

[Clevernickname]

14 hours ago, Sam A said:

 

I have a very similar set up to you @Clevernickname.... AD Initial owner: Administrator; AD initial group is Domain Admins; then I manage the permissions based on group membership; which was added by a Windows machine.  Permission like this is on the files/metadata.  I'm surprised that rewriting the permissions resolved the issue. Also, if feel like my issue was more around share permissions; not so much file permissions..  I could test the affective permissions from my domain admins account; effective permissions were good... But testing with the impacted account couldn't even access the root of the server e.g. \\<hostname>\ ; as well as the \\<hostname>\<shareName>\ ... I don't understand Unraid well enough to know if they somehow apply the same share permissions as the file permissions?  Maybe; In windows they're treated differently/independent of one another. 
I'll give that a shot after a couple more .releases.    

Hopefully they identify the issue and resolve it, or have a very clear work-around documented... Seems like a defect/bug. 

 

 

 

Ah, I actually had multiple issues, but it depended on the share:

 

1) Some shares, I could read dirs/files, but not do anything else

2) Some shares, I could not access at all (same problem as you, I think?)

3) Some shares I could read and add new files, but could not make changes.  Since I backup my families machines to the array (and then sync those folders to cloud), that meant that changed files where not being backed up.

 

I'm baffled on why the above occurred and why it was not consistent when it failed.  So far, I've got everything working again with AD.  I did see odd error messages in the logs when this happened, but I did not think to save them.  Something about the access belonging to multiple ids.