• [6.10.3] Intermittent SMB Issues After 6.10.2 Upgrade

    Geoff Bland

    By Geoff Bland

      • Urgent

    Myself and many other users are experiencing many issues with SMB shares using Windows Active Directory since upgrading to 6.10.2. Upgrading to 6.10.3 has not fixed this.

     

    This are all listed in the forum thread 

     

    My own issue is that for most of the time since upgrading to 6.10.2 I cannot access any UNRAID share with my own user account - however this is intermittent and occasionally access works fine for a day or two. A few other user accounts are affected but also some accounts are fine and have no problems.

     

    My log drive is 98% full due to very large syslog files. The syslog shows continual refused mount requests for my account and this seems to be as it cannot convert my SID to a UID.
      

    Jul 15 21:58:49 UNRAID01 smbd[****]:   check_account: Failed to convert SID S-1-5-21-XXXXXXXX-XXXXXXXX-XXXXXXXX-1105 to a UID (dom_user[DOMAIN\username)

     

    The  /var/log/samba/log.smbd log file is also full of the same error message.

     

    I also note this 

      

    root@UNRAID01:~# wbinfo -i myuser
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user myuser
root@UNRAID01:~# wbinfo -i okuser
okuser:*:NNNNNNNN:NNNNNNNNNN:okuser:/home/DOMAIN/okuser:/bin/false

     

    I can call wbinfo for all users on the UNRAID server and this gets the correct SIDs for all.

    • Upvote 2
    Go to reports Stable Releases

    User Feedback

    Recommended Comments



    pest0n

    pest0n 0

    Posted (edited)

    First off:

    I've read countless threads about samba with AD integration permissions issues on this forum with no real solution. I agree that it should be Lime who fixes these issues, however I'm also humble to the issue itself since it involves many different components which is not always in the hands of Lime. I've not tried out FreeNAS/TrueNAS AD integration, but from what I've gathered it seems they've managed to integrate it with much more success.

     

    Edit: I'm currently running version 6.12.8

     

    Second off:

    Here's what I see and face since it seems we all doesn't always face the same exact issue.

    I've followed the same instructions and tips from

    But the same issue appear to me. I tested this in a different approach just to see if the group assigned would do anything at all.

     

    Alright, so here's the suggested permissions "reset" after everything has been messed up.

    chown -R root /mnt/user/<Share>
    chgrp -R domain\ users /mnt/user/<Share>
    setfacl -R -b /mnt/user/<Share>
    chmod -R g+rwx /mnt/user/<Share>

     

    This gives full access to Domain Users group in AD, which includes EVERYONE by default. With these settings, everyone in my domain can add/change/delete as much as they want. So, let's change the group to a proper group and then in Windows add the correct permissions by group.

     

    Switched to group fs-documents-rw which includes admins that is OK to have full access.

    chown -R root /mnt/user/<Share>
    chgrp -R fs-documents-rw /mnt/user/<Share>
    setfacl -R -b /mnt/user/<Share>
    chmod -R g+rwx /mnt/user/<Share>

     

    Admins are now allowed the correct access (full), and the other users are not able to access the subfolders of the share. Then I tried to add permissions for them within Windows explorer. After confirming everything looks nice and dandy, I tested them and the exact same access denied message was delivered. Almost as if Unraid can't read/retrieve information what group the users are in. So, over to the next test.

     

    Let's try with the group I want to give them in Windows, but directly in Unraid instead. This test is to check if non-admins can be given access much like Domain Users but with a custom group (fs-landingzone-r). This test is the same as above, difference is leaving admin users out of it.

     

    chown -R root /mnt/user/<Share>
    chgrp -R fs-landingzone-r /mnt/user/<Share>
    setfacl -R -b /mnt/user/<Share>
    chmod -R g+rwx /mnt/user/<Share>

     

    They get access but with full permissions, this is expected. This confirms to me that users in this group can be read and granted access by Unraid. I went back with the most restrictive settings (admins only) and created a folder, just a folder and this applied Domain Users with none? permissions but wouldn't you know, the users with no access can access and delete this very folder. So, Windows? Unraid? added full permissions for regular users to a folder which was created by an admin without permissions it could inherit.

     

    My first thought was that, OK I'm fine with applying only one group to a share, at least it gets a bit restrictive but since new folders will just apply domain users everyone will have access anyway so I'm left with using domain users. Permissions in Windows is totally ignored so no need to bother. I've no idea if this gives anyone insight but since I've been trying to solve this for multiple days I thought I could at least share what I discovered and why I'm giving up.

    Edited by pest0n
    Corrected a wrongly entered group
    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.

    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.