unraidster

Hi, as an update, with help from support (thanks!) I was able to get hold of copies of 6.11-rc1 and 6.11-rc5. Both display the same output from the "mount | grep /mnt/user" command as 6.12.6 and both also fail to allow user share access to users with access via an ACL; throwing the same error from 6.12.6. I have also tried 6.12.7-rc2 and found the same results as 6.12.6. Unraidser

Hi, thank you both. In looking into Fuse from my last post I found a thread in this forum reporting a bug related to 6.10.0 rc5 (Link). The timing correlates with when ACLs stopped working for me with AD users and may explain that difference in behaviour between user share access and disk share access. I have provided some additional information in that post and am waiting to see if someone with some additional knowledge on Unraid and Fuse is able to advise/reply to that post. Unraidster.

I have come across this thread in my troubleshooting of ACLs failing to work in versions after 6.9.2 (post link). Thanks to @copperhound for his post (link) with a command that could provide the options that fuse is mounted with. The options returned by the command are different for 6.9.2 and 6.12.6: 6.9.2 root@UR-Lab:~# mount | grep /mnt/user shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) 6.12.6 root@UR-Lab:~# mount | grep /mnt/user shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other) Hi @limetech, is this possibly a root cause for the difference in ACL behaviour? If so, was there a change made in 6.11rc to revert some settings that hasn't made it into subsequent versions? (happy to test another version in my lab if it helps) Thanks, Unraidster

Hi, As part of my troubleshooting I tried the following test and found an interesting result. Test: Attempt to access the share contents using a disk share (rather than a user share). Note: This is a lab system, so not concerned about creating a disk share for a disk that also has user shares configured. The system only contains one disk. Method: Using a working, configured 6.9.2 installation. Upgrade to 6.12.6. Use the same test user accounts used to validate 6.9.2 to access 6.12.6 Confirmed error is thrown (see previous posts) accessing the user share. Setup a disk share (disk1). Browse to the disk share and evaluate the folder that represents the "PrivateShare" user share. Outcomes: The test users are able to access the PrivateShare folder within the disk share but are still unable to access the PrivateShare user share. Can view the ACL and can see valid ACLs (as we saw in 6.9.2) when browsing the PrivateShare folder within the disk share. I don't have a detailed knowledge of the architecture of Unraid, but I am guessing that there is a difference in the way a SMB call to the user share (/mnt/user/PrivateShare in this example) is made vs the same folder in a disk share (/mnt/disk1/PrivateShare). From what I have read so far, I believe Fuse may be one of those differences. Any knowledge/advise on the above would be appreciated :). Regards, Unraidster

Hello Everyone, I have separated the latest update into two posts, this one is some more detail on the error the next post is looking at another troubleshooting approach. I reproduced the error in 6.12.6 using the smbclient on the Unraid server (AD user credential used). I found this cuts down on the amount of "noise" in the logs vs using a Windows client. I also setup strace to record the calls made during the connection. Not being familiar with strace, I have managed to configure it to capture any processes spawned by the main smbd process and save the output to a file. I found that strace was not installed by default so used the following processes for 6.9.2 and 6.12.6 to install. Appreciate any feedback on the approach to install strace (Note: I was installing on a lab system that I tear down frequently so was not too concerned about where files were being saved etc.) Process used to install strace on 6.9.2 (run from CLI) Process used to install strace on 6.12.6 (run from CLI) I have included a snippet of the calls made around the error in 6.12.6 below. I have also included what I think are the similar calls made in 6.9.2 (where the SMB connection works). 6.9.2 - strace excerpt 6.12.6 - strace excerpt Note: The "11254 chdir("/mnt/user/PrivateShare") = -1 EACCES (Permission denied)" line in the 6.12.6 output and the similar "6920 chdir("/mnt/user/PrivateShare") = 0" line in the 6.9.2 output. I tried to interpret the two outputs, but only really established that the EACCES error is thrown when "Search permission is denied for one of the components of path". [REF] Directory Permissions/ACL Based on: 1) the ACL previously working in 6.9.2 and 2) the folder permissions (for /, /mnt, and /mnt/user) and 3) the ACL (for /mnt/user/PrivateShare) allowing a minimum of execute access to the test AD users (members of the -ro and -rw groups) I suspect something is causing the ACL to get evaluated incorrectly. Unraidser.

Hi, I sent some queries into the Samba mailing list and received some feedback from the Samba team. Unfortunately I haven’t been able to resolve the issues I have highlighted in this thread but still have some troubleshooting to work through. In the meantime the thread may be useful to others working on the same problem. https://lists.samba.org/archive/samba/2024-January/247763.html Unraidster

Hi, I am still trying to find a solution. I sent a message into the samba mailing list and have received some help and feedback but I am still unable to get an Unraid version newer than 6.9.2 working. My plan was/is to update this thread with a method/process if I find a way to get AD integration working again. Unfortunately, I have had to stay on 6.9.2 as updating breaks my configuration. @fredskis - are you using AD principals to secure access to your shares (even if it was a more limited configuration that you wanted) or did you stick to non-AD user access? If you are using AD principals, are you able to feedback any info about how you have configured that? I’ll post an update in my post with all of the issue’s technical details when I get some time. Thank You

HI Everyone, I thought I would take another look at this (as I want to upgrade from 6.9.2). Tried 6.12.6 and can confirm the issue persists when upgrading from 6.9.2. Will be taking another look to the lab to see if I can find a workaround but no successes yet. Has anyone else with this issue been able to move on from 6.9.2? if so, are you able to explain what you did? TIA!

Hello Anon, Are you able to replicate the issue and capture diagnostics? The issue you are experiencing seems to be very similar to the issue I also encounter when upgrading an existing configuration from 6.9.2 to 6.10.3+. I have a thread on it here: https://forums.unraid.net/topic/136002-upgrading-ad-integrated-692-build-private-share-access-issues/ You might also find a plugin made by Dan that can help you modify some Samba settings: https://forums.unraid.net/topic/137467-active-directory-extras-plugin-allows-tweaking-some-ad-settings-in-samba/#comment-1249136 Your goals seem to be similar to what I have working with 6.9.2 but stops working after upgrading the version of Unraid.

Hi Olax, I am troubleshooting another issue, and just had to try to do the same thing (re-join a domain). I can confirm I experienced the same in 6.9.2 (where clicking on the leave button did not do anything). In the "Joined" state, the GUI would not simply let me type the "AD account password" and click on join as the join button is greyed out. The only way I found for the GUI to allow me to "Join" the domain again was to: 1) Reset the AD Computer object account (in Active Directory) / delete the Computer account object from the AD. 2) Then reboot the unraid server The "AD join status" would now read as "Not joined" for me, allowing me to enter the "AD account password" in and click on "Join". Hope that helps, interested to hear if anyone has an easier way to do it. Thanks,

Hi Everyone, Some of us are experiencing issues with samba AD integration for file shares in Unraid. It seems to only impact setups with a specific file share configuration (I have a separate thread on the issue here: link). I would like to know if there are any Unraid users out there using a working configuration similar to the config described below. If you are, would you be able to provide a rough overview of how you have configured your file shares please? I hope this will help identify a configuration setting that may be causing our configuration to break after upgrading from 6.9.2. Unraid File Share Configuration Unraid 6.10.3 + AD Joined Unraid server Private File share where only members of a specific AD group can access the share. Those that are not members of the group are denied access to the share. Docker containers can access the share, read/write etc. Any content created/modified by the docker container can be read/written/deleted by AD users that are members of the file share’s access group. Any additional information you are able to provide about your setup will be useful for context, such as: Unraid Version IDMAP configuration (hash, tdb, rid etc) (or the output from testparm) Type of account used for initial AD User and Initial AD Group Thank you in advance for any input you are able to provide.

Hi everyone, No solution yet, but managed to find some specific log entries in Samba that may be useful for the diagnosis. I set the samba logging level to 10 and performed the same share access action in 6.9.2 and 6.11.5. 6.9.2 (successful access to share) [2023/04/20 23:02:15.891814, 5, pid=5659, effective(0, 0), real(0, 0)] ../../source3/auth/token_util.c:873(debug_unix_user_token) UNIX token of user 1278739538 Primary group is 1278738945 and contains 4 supplementary groups Group[ 0]: 1278738945 Group[ 1]: 1278739543 Group[ 2]: 1278739547 Group[ 3]: 1278739545 [2023/04/20 23:02:15.891836, 4, pid=5659, effective(1278739538, 1278738945), real(1278739538, 0), class=vfs] ../../source3/smbd/vfs.c:923(vfs_ChDir) vfs_ChDir to /mnt/user/PrivateShare [2023/04/20 23:02:15.892966, 5, pid=5659, effective(1278739538, 1278738945), real(1278739538, 0), class=vfs] ../../source3/smbd/vfs.c:985(vfs_ChDir) vfs_ChDir: vfs_ChDir got /mnt/user/PrivateShare [2023/04/20 23:02:15.893078, 5, pid=5659, effective(1278739538, 1278738945), real(1278739538, 0)] ../../source3/smbd/uid.c:293(print_impersonation_info) print_impersonation_info: Impersonated user: uid=(1278739538,1278739538), gid=(0,1278738945), cwd=[/mnt/user/PrivateShare] [2023/04/20 23:02:15.893083, 5, pid=5659, effective(1278739538, 1278738945), real(1278739538, 0)] ../../lib/dbwrap/dbwrap.c:142(dbwrap_lock_order_lock) dbwrap_lock_order_lock: check lock order 1 for /var/cache/samba/smbXsrv_tcon_global.tdb [2023/04/20 23:02:15.893086, 10, pid=5659, effective(1278739538, 1278738945), real(1278739538, 0)] ../../lib/dbwrap/dbwrap.c:129(debug_lock_order) lock order: 1:/var/cache/samba/smbXsrv_tcon_global.tdb 2:<none> 3:<none> 4:<none> 6.11.5 (access denied) [2023/04/21 22:58:11.191052, 5, pid=6250, effective(0, 0), real(0, 0)] ../../source3/auth/token_util.c:873(debug_unix_user_token) UNIX token of user 1278739538 Primary group is 1278738945 and contains 5 supplementary groups Group[ 0]: 1278739538 Group[ 1]: 1278738945 Group[ 2]: 1278739543 Group[ 3]: 1278739547 Group[ 4]: 1278739545 [2023/04/21 22:58:11.191074, 4, pid=6250, effective(1278739538, 1278738945), real(1278739538, 0), class=vfs] ../../source3/smbd/vfs.c:938(vfs_ChDir) vfs_ChDir to /mnt/user/PrivateShare [2023/04/21 22:58:11.191533, 0, pid=6250, effective(1278739538, 1278738945), real(1278739538, 0)] ../../source3/smbd/smb2_service.c:168(chdir_current_service) chdir_current_service: vfs_ChDir(/mnt/user/PrivateShare) failed: Permission denied. Current token: uid=1278739538, gid=1278738945, 5 groups: 1278739538 1278738945 1278739543 1278739547 1278739545 [2023/04/21 22:58:11.191616, 3, pid=6250, effective(1278739538, 1278738945), real(1278739538, 0), class=smb2] ../../source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../../source3/smbd/smb2_server.c:3247 [2023/04/21 22:58:11.191630, 10, pid=6250, effective(1278739538, 1278738945), real(1278739538, 0), class=smb2] ../../source3/smbd/smb2_server.c:3841(smbd_smb2_request_done_ex) smbd_smb2_request_done_ex: mid [6] idx[1] status[NT_STATUS_ACCESS_DENIED] body[8] dyn[yes:1] at ../../source3/smbd/smb2_server.c:4005 [2023/04/21 22:58:11.191637, 10, pid=6250, effective(1278739538, 1278738945), real(1278739538, 0), class=smb2_credits] ../../source3/smbd/smb2_server.c:969(smb2_set_operation_credit) smb2_set_operation_credit: smb2_set_operation_credit: requested 1, charge 1, granted 1, current possible/max 8160/8192, total granted/max/low/range 33/8192/7/33 [2023/04/21 22:58:11.194902, 10, pid=6250, effective(1278739538, 1278738945), real(1278739538, 0), class=smb2] ../../source3/smbd/smb2_server.c:4995(smbd_smb2_io_handler) smbd_smb2_request idx[1] of 5 vectors I have attached full copies of the samba log in case the additional debug information is useful to anyone, Thanks, Samba-6.9.2-Level10.log samba-6.11.5-Level10.log

Thanks Dan, I can confirm that I was able to install the plugin on 6.11.5. (Plugin version: released about 30 minutes ago, i think that was the second version) My test environment is running with a hash backend and plan to change that when I have a plan to address some other challenges. I haven't run into the "timeout" issues that some others have but I tested the plugin changing my lab backend from hash to tbd. Using testparm i am able to confirm the [global] configuration has changed from: idmap config * : range = 10000-4000000000 idmap config * : backend = hash to idmap config * : range = 3000-7999 idmap config * : backend = tdb Some thoughts: Could the script be made to run on 6.9.2 too? (I will be addressing the idmap config in 6.9.2 before I move over to 6.10.3+ and have fixed my private share issues). Would there be a way to increase the logging level in samba? (pre-empting troubleshooting on my private share issue) Thanks for all of your time creating this plugin.

Hi, I just encountered the same issue (within a lab which is running 6.11.5). Using Firefox 111.01 i get the same issue of start array > prompt > hit resubmit > stale configuration. Note: I was previously able to login to this server without this issue, cannot recall what version of Firefox I was running when i last accessed this server. Signing in via the Edge browser seems to work without such a prompt. I have attached a screenshot of the dialog. The workaround (clicking on cancel in the prompt) isn't too difficult to do but would be good to understand the root cause. I have included some diagnostics if they are of use to anyone. (captured after attempting to login via Firefox and clicking on resubmit on the dialog). Thanks, ++ Tried on 6.9.2 with the same version of Firefox and not seeing the same issue. ur-lab-diagnostics-20230406-1041.zip

Hi MD, did you ever find out why that worked? Did your access continue to work with subsequent versions? Thanks,