Upgrading AD Integrated 6.9.2 build - Private Share Access Issues

[unraidster]

Hello Everyone,

 

Apologies in advance for the long post. I have been troubleshooting the upgrade of an Active Directory integrated 6.9.2 environment on and off for a few months now. Each time I attempt to upgrade I end up reverting back to 6.9.2 to get access to shares working again. During my troubleshooting I have found two key differences in the environment after the upgrade (most recently to 6.11.5).

 

I have setup a configuration within a lab environment that closely mimics the main environment to help me revert the configuration and try different configuration changes out. I am able to reproduce the issues I have in the main environment within this lab.

 

The changes I have identified after the 6.9.2 > 6.11.5 upgrade are:

 

• Access to a "private" share using windows no longer works.
  • A User on a windows client is presented with a "Windows cannot access…" "Network Name cannot be found" 0x80070043 Error.
• The Unraid log records the following error:

Mar  5 00:48:23 UR-Lab  smbd[6151]: [2023/03/05 00:48:23.788115,  0] ../../source3/smbd/smb2_service.c:168(chdir_current_service)
Mar  5 00:48:23 UR-Lab  smbd[6151]:   chdir_current_service: vfs_ChDir(/mnt/user/PrivateShare) failed: Permission denied. Current token: uid=1278739537, gid=1278738945, 4 groups: 1278738945 1278739544 1278739542 1278739546

 

• Access to private shares using the Krusader docker container (default configuration) no longer works.
  • This was also experienced with other docker containers that have mapped host paths.
  • I don't see any errors in the Unraid log when this access attempt fails.

 

I think there might be a couple of root cases here, but so far have failed to identify what those are. I have tried a variety of changes that included re-applying permissions (using the new permissions feature) without being able to resolve both issues above (please see below for more detail).

 

Having read other posts on the forum, I think the following notes may be useful info/context to folks looking at this post:

• Spoiler

  • The AD User accounts can be looked up after the upgrade to 6.11.5 (using ID {username}) and wbinfo -n {username}.
    • The IDMAP of the environment is still the system's original default HASH based setting. I intend to change this to a RID IDMAP in the future to prevent future issues. But I do not think this is the root cause of the issues I see above due to the lookups working correctly. Once  I have a root cause/solution to the issues above I will probably test a change to the IDMAP (and inevitable re-permission) in concert with any other changes that need to be made.
  • Private Share Configuration - How the shares are created:
    • UR SMB setting - Initial AD user is set to an AD admin account. Initial AD Group is set to an AD access group that only an admin account is a member of.
    • Private Share is created.
    • Accessed using the Initial AD User admin account from Windows.
    • The Initial AD Admin account and Initial AD Group ACL entries are set to "This folder, all subfolders and files"
    • Additional share specific RO and RW AD groups are added with respective read-only or Full control permissions. The scope is again set to "This folder, all subfolders and files".
    • The "Replace all child object permission entries with inheritable permission entries from this object" is selected.
    • Click on apply.
    • Remove the Everyone permission.
    • The "Replace all child object permission entries with inheritable permission entries from this object" is selected.
    • Click on apply.
    • This results in a share that only members of the Initial AD Group, RO, or RW groups are able to access. Docker containers with the path mapped are able to essentially perform any action (RWX).
  • The Krusader docker container is configured with:
    • UMASK 000, PUID 99, PGID 100
  • I have tried to reset the permissions with the "New Permissions" tool.
    • The share did become accessible (Windows and Docker), but that was because an "Everyone" permission was added. I checked the remainder of the permissions, which included those that were added previously as part of the configuration detailed above.
    • On removal of the everyone permission, Windows reports it is unable to remove the permissions from some of the folder (I think those that were previously created by Krusader).
    • The share became inaccessible to windows users, but was accessible to Krusader (presumably because an explicit nobody or users permission had been added to the ACL by the tool). Happy to explore this if recommended to do so.
  • I have included the diagnostics and some outputs from testparm and permissions listings as an attachment to this post. The 6.9.2 prefixed files are from the environment before the upgrade (working state), and those pre-fixed 6.11.5 are those after the upgrade where the issues occur.
  • Public share access functions as expected (accessible for domain joined users in Windows, and host path mapped docker containers) both before and after the upgrade.

 

In summary, I suspect there are a couple of changes to the way things work between 6.9.2 and (6.10.3-6.11.5). I would like to understand if any differences are resulting in my experiences and then work out what to change to get back to the same functionality.

 

Thank you to anyone that endured reading through all that and for any assistance they are able to provide. Please let me know if there is any additional information I can provide or things you would like me to try. Thanks.

6.9.2_PrivateShare_Permissions.txt 6.9.2_testparm.txt 6.9.2_ur-lab-diagnostics-20230305-0024.zip 6.11.5_Permissions.txt 6.11.5_testparm.txt 6.11.5_ur-lab-diagnostics-20230305-0053.zip

[unraidster]

Hi, 

 

To add to the information above, here are some outcomes from other tests.  

 

• The environment can be rolled back to 6.9.2 and the errors cease. 
• The errors occur on upgrade from 6.9.2 to 6.10.3. 

This makes me think that the errors I am encountering are introduced with 6.10.3. 

 

Any thoughts/help are welcome. Thanks,

[psychofaktory]

Thanks for the write up on this topic.

 

It sounds like the exact same error pattern as I had described here:

https://forums.unraid.net/bug-reports/stable-releases/6103-intermittent-smb-issues-after-6102-upgrade-r2028/?do=findComment&comment=20618

 

I also think that this is a different additional problem than the one mainly described here.

 

I sincerely hope that the Unraid team will take the information you have provided and finally fix this bug.

 

The bug has been known for several months now. And although this is a business issue, nothing has been done about it yet. Even more: it was even noted that the priority of the bug fix was set very low here.

Especially for customers who use Unraid in a business environment, this is an absolute core function with the highest security relevance.

The question of how many Unraid users use this function and would benefit from the bug fix is irrelevant.

 

Therefore, immediate bug fixing should be absolutely in the interest of the Unraid team.

[unraidster]

Thanks @psychofaktory, appreciate the feedback and glad to see that it is not just isolated to my environment.

[unraidster]

Hi, I noticed that 6.12.0-rc1 is out (LINK), and out of curiosity I thought I would give it a go by upgrading the working 6.9.2 build to 6.12.0-rc1. Unfortunately I continue to encounter the same error. Thought it was worth a try. 

 

The modified GUI looks nice though

Edited Thursday at 09:25 PM by unraidster