• [6.10.3] Intermittent SMB Issues After 6.10.2 Upgrade


    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



    User Feedback

    Recommended Comments



    Thanks to the help by a guy from the Samba Support mailing list I think I am getting somewhere.  I have at least managed to get access to my Unraid shares for all AD users - although all the permissions are now messed up and need re-applying. 

     

    It looks like the Unraid SMB configuration is just plain wrong for the version of Samba installed. The Unraid SMB configuration uses a way to map AD users to local users that has been unsupported for over 5 years now and there's explicit warnings not to use it. Reconfiguring to use a different method for ID mapping was what got me working. 

     

    Currently I am working with the Samba Support mailing list to work out what the "best" way is to configure this - as soon as I have that figured out I will post here. 

    Edited by Geoff Bland
    • Like 2
    • Upvote 2
    Link to comment

    Caveat - read carefully - I am by no means an UNRAID expert nor an expert on Samba, this is just want I have found out by reading online documentation and have been advised of on the Samba mailing lists. You should be really sure of what you are doing before you attempt this - you are responsible for your own files and data

     

    It is really unhelpful that someone from Unraid has not responded to this issue with an official solution as this seems to be affecting many users and this does appear to be a misconfiguration issue with Unraid.

     

    The problem appears to be that Unraid is using a later version of the Samba Service but with an ID mapper (idmap_hash) that was end of life over 5 years ago and is known to cause issues. The fix is to "correct" Unraid's standard server configuration for Samba to use the correct ID mappers. 

     

    These sites were of particular use:

     

    https://support.microfocus.com/kb/doc.php?id=7007006
    https://lists.samba.org/mailman/listinfo/samba
    https://www.samba.org/samba/docs/current/man-html/
    https://www.samba.org/samba/docs/current/man-html/idmap_hash.8.html
    https://www.samba.org/samba/docs/current/man-html/idmap_tdb.8.html
    https://www.samba.org/samba/docs/current/man-html/idmap_rid.8.html

     

    This did fix the problem with Samba shares not being accessible to certain Windows domain users for me. BUT after this fix, as user IDs get changed, most permissions were messed up and needed to be re-applied. 

     

    Use this fix at your own risk.

     

    It is also helpful to know the

    wbinfo -i <username>

    command to check the the ID lookup is working correctly against your domain. 

     


    Fix UNRAID Samba Access Issues.

     

    Open the Unraid terminal, ">_" button on top of each Unraid page. 

     

    First back up smb-extra.conf  file as follows:

    cp /boot/config/smb-extra.conf /boot/config/smb-extra.conf.bkp

     

    Edit the contents of /boot/config/smb-extra.conf and add these lines, replacing <SHORT_DOMAIN_NAME> with the name of your domain (the same as appears in the "AD short domain name" field of your Unraid SMB settings):

    [global]
    idmap config * : backend = tdb
    idmap config * : range = 1000-7999      
    idmap config <SHORT_DOMAIN_NAME> : backend = rid
    idmap config <SHORT_DOMAIN_NAME> : range = 10000-4000000000

     

    The idea is that RID ID mappings are consistent and a given domain account will always map to the same local ID on Unraid, so if for some reason the IDs get reset the same domain accounts will remap to the same local IDs and retain access rights. Also a range of tdb IDs is assigned in case any SMB accounts are used without a domain. 

     

    This will be shown as "extra configuration" on the Unraid SMB Settings page. Other Unraid plugins (such as unassigned devices) may also add configuration to this same smb-extra.conf - leave these as is and just add these extra lines to the top.

     

    Then reboot Unraid (just restarting the SMB service does not work fully).

     

    Finally check and fix all your permissions.

     


    Reset/Re-apply UNRAID Permissions.

     

    Open the Unraid terminal, ">_" button on top of each Unraid page. 

    Run the following commands where <share> is the name of the share (each can take a long time if you have many files). 

    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>

     

    If you need Windows permissions on the folder then apply permissions via Windows (NOT via Unraid Share SMB User Access settings).

    1. Open UNRAID Shares in File Explorer.
    2. Right click on the Share, select Properties.
    3. Select Security tab.
    4. Click "Advanced".
    5. Add, remove and alter permissions as required - note you may need to check the "Replace child object permissions" options to get this to work properly. 
    6. Hit apply  
    7. If using NFS from this share just refresh it (add/delete a space on the NFS rule and hit Apply) on UNRAID for some reason these seem to lose access rights when Windows changes the permission even when they should not. 

     

    Edited by Geoff Bland
    • Like 1
    Link to comment
    On 7/27/2022 at 1:04 PM, Geoff Bland said:

     

    Edit the contents of /boot/config/smb-extra.conf and add these lines, replacing <SHORT_DOMAIN_NAME> with the name of your domain (the same as appears in the "AD short domain name" field of your Unraid SMB settings):

    [global]
    idmap config * : backend = tdb
    idmap config * : range = 1000-7999      
    idmap config <SHORT_DOMAIN_NAME> : backend = rid
    idmap config <SHORT_DOMAIN_NAME> : range = 10000-4000000000

     

    The idea is that RID ID mappings are consistent and a given domain account will always map to the same local ID on Unraid, so if for some reason the IDs get reset the same domain accounts will remap to the same local IDs and retain access rights. Also a range of tdb IDs is assigned in case any SMB accounts are used without a domain. 

     

    Geoff,

     

    Thank you for posting this.  My SMB mappings crapped out suddenly again today and shouldn't have, I run both a virtual AND a backup physical DC in UPS's to make sure my uptime is 5-nines, so it shouldn't have lost connectivity, and especially not 3 times in the last month. So it was time to start digging into what's going on.

     

    Like everyone else, My issues started happening when I upgraded to 6.10.2 and persisted in 6.10.3.

     

    There was a similar posting in the original thread talking about this before the ticket was created, and while @harpesichord's fix there was very similar, it looks like they limited the idmap config range for the domain (fqdn seems to work fine here too, and I was able to add these easily into my extra config file in the GUI under [global]) to 10000-999999. While I doubt this makes a difference (unless you have more than 998,999 groups and users), I'm wondering if Limetech fixes this in the next release, that it'll re-set everyone's permission mappings yet again - or if those are persistent unless we run the additional code to reset the variables and smb mappings that you also posted?

     

    Just thinking about if we'll need to re-do our permissions setups yet again when it gets fixed.

     

    Link to comment
    1 hour ago, Alyred said:

    Just thinking about if we'll need to re-do our permissions setups yet again when it gets fixed.

    My understanding is if you use the rid idmap settings then a given AD domain user will always map to the same local ID and so permissions should not need to be reset.

    • Like 1
    Link to comment

    @Geoff Bland It's been over a week, how have things been running for you since your config edits were made? 

     

    I just had an important user account fall off moments ago, during the middle of a 2 day parity rebuild, so it's fresh in my mind...

     

    Assuming everything is going well I'll be making these changes the moment I'm able to reboot again.

    Link to comment
    1 hour ago, CallOneTech said:

    @Geoff Bland It's been over a week, how have things been running for you since your config edits were made? 

     

    It's been 2 weeks now since I made the change. I've had no problems since.

    I was pretty sure it was working straight away as prior to this I was having continual problems and repeating errors showing in the logs - since the fix nothing.

    As stated, I had to reset access on all files after doing this, but that is complete now and I checked this all again today and it is good. Have to remember to use Windows to set permissions though. 

     

    Link to comment
    9 hours ago, Geoff Bland said:

     

    It's been 2 weeks now since I made the change. I've had no problems since.

    I was pretty sure it was working straight away as prior to this I was having continual problems and repeating errors showing in the logs - since the fix nothing.

    As stated, I had to reset access on all files after doing this, but that is complete now and I checked this all again today and it is good. Have to remember to use Windows to set permissions though. 

     

     

    I've also seen no problems since the changes, around the same time - About 2 weeks. I haven't finished rebuilding my permissions yet (still have a lot of the old ID numbers in a few of the shares) but the ones I did rebuild have been working solid. 

     

    Thanks again for finding and posting about those. Has allowed me to branch out to other projects...

    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.