• [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 3
    • Upvote 4
    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 3
    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...

    • Like 1
    Link to comment

    I ran into this issue as well, and Geoff Bland's solution worked for me. However, I found a way to make it even better and not have to reset any permissions! I don't know if it will work for everyone, but it worked for me and all my AD users and groups kept the same uids.

     

    First you need the uid of any AD user - you can get this with 'wbinfo -i <username>' or by looking at file permissions ('ls -n' will show the numeric user IDs instead of converting them).

     

    Then you need the RID of that user.  You can get the RID with 'wbinfo -n <username>' or in active directory look at the objectSID property for the user.  The RID is the last section of the SID.

     

    In my system:

    • UID for my user is 1161823314
    • SID for my user is S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1106, so my RID is 1106.

     

    Subtract the RID from the UID. That gives me 1161822208. I don't know if that number will be different for everyone. I'm guessing it will be.

     

    Then set the start of the range for the id mapping to that value. The rid mapper adds your RID to the low end of the range, so all your uids should match what they used to be.

     

    Same as in Geoff's solution, edit /boot/config/smb-extra.conf and add this to the [global] section:

     

    # Override unraid's use of the broken idmap_hash plugin for mapping AD SID -> uid.
    idmap config * : backend = tdb
    idmap config * : range = 1000-7999
    idmap config MYDOMAIN : backend = rid
    idmap config MYDOMAIN : range = 1161822208 - 4000000000
    

     

    Then reboot the server. Just restarting samba doesn't work, and I didn't fight with it long enough to figure out why. But rebooting does work.

     

    Once that's done, you can run 'testparm' to see the final configuration samba is using. It should include your idmap config lines, and should NOT include the default 'idmap config * : backend = hash' anymore.

     

    Test your users with 'wbinfo -i username' and make sure their user IDs all match what they were before, and that any broken users work now. No need to reset any file permissions!

     

     

    Edited by GrantE
    • Like 1
    Link to comment

    Hello Everyone - 

     

    This is a fantastic thread so glad I found it, as I am having the same issues as all of you.  We use this in a high school class where we have our own AD domain and use unraid for our network shares.  We have two domain controllers running Windows 2019 Datacenter Server fully updated running in VM on ESXI.  

     

    Everything was fine in version 9 but update to version 10 and kapow, network shares are going crazy.  Geoff I plan on giving your fix to my students who are my system admins and seeing if they can apply it.  This is going to be a great learning experience for them.  I also have another team building a new unraid box and we will apply your fix before joining to the domain.  I will report back here on our progress.  

     

    Hopefully the Unraid team is addressing this, it is unfortunate that they have not addressed it earlier, given the time it has been an issue and the amount of users it is effecting.  I will be reporting the bug today.

     

    Thanks again everyone for all of your input.  What a great community!

    • Like 1
    Link to comment

    Hello,

    unfortunately I also had massive problems with the SMB shares after joining the domain.

    I have already posted files about this here and here.

     

    The fix mentioned by @Geoff Bland with the additions by @GrantE unfortunately did not solve the access problems, but made them even worse:

     

    • the UNIX share permissions of all directories were changed to owner:administrator and group:domain-admins.
      Also those of the appdata directory.
    • before, despite the domain connection, I could create local Unraid users and give them permissions on the share. However, after the adjustment, the locally created users no longer had access to the shares.
    • when I then wanted to remove a locally created user and add it again, I unfortunately found that the user could no longer be added.
    • I then wanted to leave the domain again in order to be able to rejoin it. However, I discovered that I could no longer leave the domain because the "Leave" button had no function.
    • after resetting the permissions as recommended by @mgutt I discovered that the permissions of the share folders under /mnt/user (without inheritance to the subfolders) were reset to owner:administrator and group:domain admins without my intervention.

     

    The server was set up with Unraid 6.10.3, so unfortunately I have no experience with earlier Unraid versions.

     

    I really hope that the Unraid developers take care of this in a timely manner.
    Share permissions are one of the essential components of a file server, and it is precisely because of the AD connection that mainly companies are affected by the error.
    In my case, a small school, which leads to considerable problems in the process there.

    • Like 1
    Link to comment
    Quote

    the UNIX share permissions of all directories were changed to owner:administrator and group:domain-admins. Also those of the appdata directory.

     

    This is probably as expected. As mentioned after the fix I posted above all permissions need to be reset.
    For a brand new share the owner would be set as the SMB settings Initial Owner and group set as the  SMB settings Initial Group (this defaults to the account used for SMB settings and the user group set to Domain Users I think).

     

    Quote

    before, despite the domain connection, I could create local Unraid users and give them permissions on the share. However, after the adjustment, the locally created users no longer had access to the shares.
    when I then wanted to remove a locally created user and add it again, I unfortunately found that the user could no longer be added.

     

    Did you try to use UNRAID created users to set the permissions on the share?
    As mentioned above, apply permissions via Windows NOT via Unraid Share User Access settings. As far as I know there is no current way to keep "UNRAID" created users in step with the Windows AD users. 

    Create test user on Windows AD - do NOT create this user on UNRAID. Try resetting the permissions and then use Windows File Manager to reapply permissions for the test user on their share using the steps I posted above. Hopefully that will work.

     

    UNRAID created users and permissions did use to work OK but since release 6.10.2 have not according to most reports on this thread and others.

     

    Quote

    I then wanted to leave the domain again in order to be able to rejoin it. However, I discovered that I could no longer leave the domain because the "Leave" button had no function.

     

    This has been reported several times I think, I have had the same problem. I am not sure if this is related to SMB issues but a completely separate issue. The only way I found to leave and rejoin the domain was to reboot UNRAID, obviously not great. 
     

    Edited by Geoff Bland
    Link to comment
    20 minutes ago, Geoff Bland said:

    This is probably as expected. As mentioned after the fix I posted above all permissions need to be reset.
    For a brand new share the owner would be set as the SMB settings Initial Owner and group set as the  SMB settings Initial Group (this defaults to the account used for SMB settings and the user group set to Domain Users I think).

    This surprises me, as I had made the adjustments to the range mentioned by @GrantE.
    There it said that there was no need to reset the file permissions.

     

    21 minutes ago, Geoff Bland said:

    Did you try to use UNRAID created users to set the permissions on the share?

    No, I had reset the permissions as you described in your post after I noticed that something had changed here.
    I then adjusted the security permissions for the shares from Windows.
    However, although the share permissions were adjusted, I could not access the share with the users who were now authorised to do so according to Windows.
    Unfortunately, this is still exactly the same error as before.

    I only created the local Unraid user for testing purposes.
    In the process, I noticed that after the adjustment of the smb-extra.conf described here, I can no longer access shares with a previously created Unraid user, and I can no longer create new Unraid users.

     

    28 minutes ago, Geoff Bland said:

    The only way I found to leave and rejoin the domain was to reboot UNRAID, obviously not great. 

    I had read about the workaround.
    However, the Unraid server was restarted directly before...

    • Like 1
    Link to comment
    Quote

    No, I had reset the permissions as you described in your post after I noticed that something had changed here.
    I then adjusted the security permissions for the shares from Windows.
    However, although the share permissions were adjusted, I could not access the share with the users who were now authorised to do so according to Windows.

     

    That's weird then. It sounds like you have a different problem to the one we had. For us if Windows states a user has access then that access has worked for us. 

    You may be able to get to the bottom of it using the wbinfo and getfacl commands to see what is going on.

     

    Link to comment
    12 hours ago, Geoff Bland said:

    You may be able to get to the bottom of it using the wbinfo and getfacl commands to see what is going on.

    In my previous tests, I had already read out this information and everything looked good so far.

     

    Originally I simply followed these instructions and the experiences from this post.

    I had already noticed that something must have changed, as the instructions could no longer be used in this way.
    In contrast to the instructions, I first had to manually change the owner to the Windows user with which I manage the permissions.

     

    After I had set the authorisation via Windows as desired, I checked the "effective authorisations" via Windows and tested whether the authorisations were effective.
    There I was shown that the access exists.

     

    I used getfacl to cross-check the permissions from Unraid. Everything looked good there too.

    In the practical test, however, I could not access the share with the user for whom the effective permissions were displayed as "full access".
    The same error message was displayed as in your initial post.

    During further tests, I then found that access from Windows is only possible for users if either "everyone" has access rights or the Windows user is a member of the UNIX group of the share.

     

    The problem is, however, that I can only store one UNIX group.
    However, I have different groups that should have different access rights.
    I also have a Nextcloud docker that also uses the share via the "External Storage" plugin. And for this, the UNIX group must be set to "users".

    In itself, this should work. Unfortunately, it does not work at all.

     

     

    What can I do to find the cause of the fault and be able to rectify it?
    To be honest, I'm a bit helpless here.

    Link to comment
    Quote

    Originally I simply followed these instructions and the experiences from this post.

    This used to work fine but it seems since 6.10.2 many have found it no longer worked and hence this alternate way of doing this.

     

    Quote

    After I had set the authorisation via Windows as desired, I checked the "effective authorisations" via Windows and tested whether the authorisations were effective.
    There I was shown that the access exists.
    I used getfacl to cross-check the permissions from Unraid. Everything looked good there too.
    In the practical test, however, I could not access the share with the user for whom the effective permissions were displayed as "full access".

    The solution I posted above relies on the Windows permissions working and user IDs being assigned from the domain user IDs. I believe the only thing I have different from you is you have set up the domain Administrator as the SMB login account whereas I have a specific `unraid` account to do this but I don't think this makes a difference. 

     

    For example, if I select a file in my own share on UNRAID and list the access rights:

    root@UNRAID02:# getfacl /mnt/user/Geoff/Work/charlie.jpg 
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/user/Geoff/Work/charlie.jpg
    # owner: geoff
    # group: domain\040users
    user::rwx
    user:domain\040admins:rwx
    user:domain\040users:---
    user:unraid:rwx
    group::---
    group:domain\040admins:rwx
    group:domain\040users:---
    group:geoff:rwx
    group:unraid:rwx
    mask::rwx
    other::---

    I can see that the access rights assigned by Windows are present and as expected. 

     

    I can then also confirm that users' accounts are the correct Windows ones:

    root@UNRAID02:# wbinfo -n geoff
    S-1-5-21-2xxxxxxx9-4xxxxxxxx9-3xxxxxxx2-1105 SID_USER (1)
    root@UNRAID02:# wbinfo -s S-1-5-21-2xxxxxxx9-4xxxxxxxx9-3xxxxxxx2-1105
    <DOMAIN>\geoff 1
    root@UNRAID02:# id -u geoff
    11105

     

    If this is not working - as your experience seems to suggest is the case then I am not sure what to do to take this further.

     

    Edited by Geoff Bland
    Link to comment

    Thank you for the new input.

    I have carried out new tests based on this.

     

    First I restarted Unraid, and immediately afterwards I left the domain, which also worked.
    Apparently the domain join function is related to the start of the array. At that point, it had not yet been started.

     

    Then I removed the created entries from smb-extras.conf and restarted Unraid again.
    I then added the entries again. This time, however, I used your example @Geoff Bland instead of the adjustments described by @GrantE.
    Then I rejoined the domain and restarted Unraid again.

    For the domain join, I did not use the administrator this time, but a Unraid user without special rights that I had created especially for this purpose.

     

    After the domain join, the UNIX permissions for all share folders were again user:administrator; group:domain-admins; 0777.

    I adjusted this to user:administrator; group:users; 0777.

    getfacl /mnt/user/Lehrer
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/user/Lehrer
    # owner: administrator
    # group: users
    user::rwx
    group::rwx
    other::rwx

     

    Here is the configuration of my smb-extra.conf:

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end
    hide unreadable = yes
    access based share enum = yes
    [global]
    # Override unraid's use of the broken idmap_hash plugin for mapping AD SID -> uid.
    idmap config * : backend = tdb
    idmap config * : range = 1000-7999
    idmap config <DOMAIN> : backend = rid
    idmap config <DOMAIN> : range = 10000-4000000000

     

    That was the output of testparm:

    testparm
    Load smb config files from /etc/samba/smb.conf
    lpcfg_do_global_parameter: WARNING: The "null passwords" option is deprecated
    Loaded services file OK.
    Weak crypto is allowed
    
    Server role: ROLE_DOMAIN_MEMBER
    
    Press enter to see a dump of your service definitions
    
    # Global parameters
    [global]
            disable spoolss = Yes
            ldap ssl = no
            load printers = No
            logging = syslog@0
            multicast dns register = No
            ntlm auth = ntlmv1-permitted
            null passwords = Yes
            os level = 100
            printcap name = /dev/null
            realm = <DOMAIN>.LOCAL
            security = ADS
            server min protocol = NT1
            server multi channel support = No
            server string = xxxxxxxxxxxxxxx
            show add printer wizard = No
            unix extensions = No
            winbind use default domain = Yes
            workgroup = <DOMAIN>
            idmap config <domain> : range = 1938817024 - 4000000000
            idmap config <domain> : backend = rid
            idmap config * : range = 1000-7999
            idmap config * : backend = tdb
            access based share enum = Yes
            acl allow execute always = Yes
            acl group control = Yes
            aio read size = 0
            aio write size = 0
            dos filemode = Yes
            hide dot files = No
            hide unreadable = Yes
            include = /etc/samba/smb-shares.conf
            inherit acls = Yes
            inherit permissions = Yes
            invalid users = root
            map acl inherit = Yes
            map archive = No
            use sendfile = Yes
            wide links = 

     

    Then, from Windows, I set the permissions again as desired.
    Once again, Windows confirmed access in the effective permissions.

     

    Under getfacl it now looked like this:

    getfacl /mnt/user/Lehrer
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/user/Lehrer
    # owner: administrator
    # group: users
    user::rwx
    user:lehrer:rwx
    user:scan:r-x
    group::rwx
    group:users:rwx
    group:administrator:rwx
    group:lehrer:rwx
    group:scan:r-x
    mask::rwx
    other::---
    default:user::rwx
    default:user:administrator:rwx
    default:user:lehrer:rwx
    default:group::---
    default:group:users:---
    default:group:lehrer:rwx
    default:mask::rwx
    default:other::---

     

    I have also checked the user assignment in Unraid:

    wbinfo -n Scan
    S-1-5-21-19xxxxxxxx-29xxxxxxxx-31xxxxxxxx-1325 SID_USER (1)
    
    wbinfo -s S-1-5-21-19xxxxxxxx-29xxxxxxxx-31xxxxxxxx-1325
    <DOMAIN>\scan 1
    
    id -u Scan
    11325

     

    But when it came to the practical test, there was disappointment again:
    The users who should have access according to the permissions only see the error message from the screenshot in the opening post.

    Only when I set the UNIX permissions back to 0777, and thus release access for "everyone", is access possible again.

     

    Edited by psychofaktory
    Link to comment

    Two things from testparm stand out that don't look as I would expect:

     

    realm = <DOMAIN>.LOCAL

     

    This should be your fully qualified domain name - unless LOCAL is your top level domain as set on your domain server & DNS?

     

    idmap config <domain> : range = 1938817024 - 4000000000
    idmap config <domain> : backend = rid

     

    The range here should be as you set it in the SMB config  smb-extra.conf file. The range should be 10000-4000000000 and not 1938817024 - 4000000000. From the wbinfo you can see that the range applied is adding 10000 so it doesn't match up with the testparm reported SMB settings. I am not sure why this would be so if the settings are there in the  smb-extra.conf file.

     

    For comparison here's what I get from testparm:

     

    realm = <DOMAIN>.<COMPANYNAME>.COM
    ...
    idmap config <domain> : range = 10000-4000000000
    idmap config <domain> : backend = rid

     

    One other thing I have is

     

    server min protocol = SMB2

     

    This is not a setting I have set anywhere on UNRAID, I see you have this set to NT1 - I am not sure what effect this would have.

     

    PS You left your domain name in the wbinfo print out.

    Link to comment
    7 hours ago, Geoff Bland said:

    This should be your fully qualified domain name - unless LOCAL is your top level domain as set on your domain server & DNS?

    Yes, the domain suffix is indeed .local.

     

    7 hours ago, Geoff Bland said:

    The range here should be as you set it in the SMB config  smb-extra.conf file. The range should be 10000-4000000000 and not 1938817024 - 4000000000. From the wbinfo you can see that the range applied is adding 10000 so it doesn't match up with the testparm reported SMB settings. I am not sure why this would be so if the settings are there in the  smb-extra.conf file.

    You are right.

    I had accidentally posted the old configuration with @GrantEs adjustments.
    In fact, the smb-extra.conf already looked like this yesterday:

    #unassigned_devices_start
    #Unassigned devices share includes
       include = /tmp/unassigned.devices/smb-settings.conf
    #unassigned_devices_end
    hide unreadable = yes
    access based share enum = yes
    [global]
    # Override unraid's use of the broken idmap_hash plugin for mapping AD SID -> uid.
    idmap config * : backend = tdb
    idmap config * : range = 1000-7999
    idmap config GSR-L : backend = rid
    idmap config GSR-L : range = 10000-4000000000

     

    7 hours ago, Geoff Bland said:

    One other thing I have is

     

    server min protocol = SMB2

     

    This is not a setting I have set anywhere on UNRAID, I see you have this set to NT1 - I am not sure what effect this would have.

    After my post yesterday ist set netbios to off to do some further testing.

    Now testparm looks like this:

    testparm
    Load smb config files from /etc/samba/smb.conf
    lpcfg_do_global_parameter: WARNING: The "null passwords" option is deprecated
    Loaded services file OK.
    Weak crypto is allowed
    
    Server role: ROLE_DOMAIN_MEMBER
    
    Press enter to see a dump of your service definitions
    
    # Global parameters
    [global]
            disable netbios = Yes
            disable spoolss = Yes
            ldap ssl = no
            load printers = No
            logging = syslog@0
            multicast dns register = No
            ntlm auth = ntlmv1-permitted
            null passwords = Yes
            printcap name = /dev/null
            realm = <domain>.LOCAL
            security = ADS
            server min protocol = SMB2
            server multi channel support = No
            server string = xxxxxxxxxx
            show add printer wizard = No
            unix extensions = No
            winbind use default domain = Yes
            workgroup = <domain>
            idmap config <domain> : range = 10000-4000000000
            idmap config <domain> : backend = rid
            idmap config * : range = 1000-7999
            idmap config * : backend = tdb
            access based share enum = Yes
            acl allow execute always = Yes
            acl group control = Yes
            aio read size = 0
            aio write size = 0
            dos filemode = Yes
            hide unreadable = Yes
            include = /etc/samba/smb-shares.conf
            inherit acls = Yes
            inherit permissions = Yes
            invalid users = root
            map acl inherit = Yes
            map archive = No
            use sendfile = Yes
            wide links = Yes

    But practicaly that didn't made a difference.

    Link to comment

    I have followed this thread and other similar one’s in the hope they will lead to resolution of the same \ similar issue I have. Unfortunately, that is proving to not be the case, here is my issue to add. If anyone can at all see what I am doing wrong please say as my sanity is slowly leaving the building.

     

    I have Unraid Trial version running. I want to see if it is right for what I need….

    Unraid has 20 shares setup and AD joined. AD server is a VM on another physical server so not a VM on Unraid. I have 1 Windows 10 VM on Unraid others a physical Windows 10 devices.

     

    My issue is, it really seems to depend on the wind direction if I can access AD managed shares on Unraid and also which account can access them. I have the added elements discussed here added to smb config. My config matches the recommended settings discussed in this thread.  I can add all those details if anyone wants to check.

     

    I can check (getfacl) and shows users have access but when they try to access, they get access denied unless I set permissions to everyone full control. Which sort of negates all the aspects of file level security.

     

    I can query the SID for accounts fine but still get the smb access errors on some account on certain shares. Done a reset of all permissions several times and seem to be in a loop of needing to redo that for it all to stop working and start again. Some times I can access shares on Unraid, other times I cannot and have no access to any shares on Unraid for any account. Several restarts and join \ leave AD (leave takes multiple attempts to leave) seems to fix that for a period of time, it really is all hit or miss. I have considered starting from scratch but to rebuild and data transfers is looking like a week activity.

     

    Unraid brings with it some major positives I want for the disk side of things where I can use different sized disks. The file access from AD is making this a no-go area as it is all well and good having flexible storage but no use if you cannot manage those shares when you have AD deployed and this is supposed to work with AD. You can get away with this on a free product but not something you have to pay to use.

     

    What does concern me is a distinct lack of engagement from Unraid Devs on what is an issue impacting multiple paying customers of their product. I guess the only positive is there is a very helpful community trying to solve this but the lack of product owner input is bad.

    • Like 1
    Link to comment

    When trying to access a share with an (actually) authorised user, the following appears in the log:

    smbd[7353]:   chdir_current_service: vfs_ChDir(/mnt/user/Lehrer) failed: Permission denied. Current token: uid=11284, gid=10513, 10 groups: 11284 10513 11317 11132 11131 11324 1003 1004 1005 1001

    With "wbinfo -n", "wbinfo -s" and "id -u" I checked the IDs for the user in question and the group that should have full access according to Windows.
    The user in question has the ID 11284.
    He is a member of the group with the ID 11132 ("Lehrer"), which should have full access.

    getfacl /mnt/user/Lehrer/
    getfacl: Removing leading '/' from absolute path names
    # file: mnt/user/Lehrer/
    # owner: administrator
    # group: users
    user::rwx
    user:domänen-admins:rwx
    user:lehrer:rwx
    user:scan:r-x
    group::rwx
    group:users:rwx
    group:administrator:rwx
    group:domänen-admins:rwx
    group:lehrer:rwx
    group:scan:r-x
    mask::rwx
    other::rwx
    default:user::rwx
    default:user:administrator:rwx
    default:user:domänen-admins:rwx
    default:user:lehrer:rwx
    default:group::---
    default:group:users:---
    default:group:administrator:rwx
    default:group:domänen-admins:rwx
    default:group:lehrer:rwx
    default:mask::rwx
    default:other::---

     

    According to

    wbinfo --gid-info 10513

    the group with ID 10513 is "domain-user".

    The test user is also in this group, but it does not have access to the share in question.

    Where is the error here and what would a permitted access attempt look like?

    Edited by psychofaktory
    Link to comment
    2 minutes ago, dlandon said:

    Has anyone tried 6.11-rc5?  Samba is updated to 4.16.5.

    I don't want to test this since I have to work with my Unraid server in a productive environment.

    Link to comment
    15 minutes ago, dlandon said:

    Has anyone tried 6.11-rc5?  Samba is updated to 4.16.5.

    If I decide to restart I will try it, as at the moment it is either get Unraid working or back to Windows Server as the host and managing the disks with Hyper-V for VM's.

    Link to comment
    4 hours ago, psychofaktory said:

    Where is the error here and what would a permitted access attempt look like?

     

    I can't see an error in your set-up. All looks correct.

     

    When I access UNRAID shares from my Windows server with an account that has access I don't see anything in the log.

    If I access an UNRAID share with an account that does not have access I get "Permission denied" warnings such as yours in the logs.

     

    It's a long shot but does "smbstatus -S" show anything unexpected?

     

    4 hours ago, dlandon said:

    Has anyone tried 6.11-rc5?  Samba is updated to 4.16.5.

     

    Interesting - although the current version on UNRAID 6.10.3 is not that old and uses Samba 4.15.7.

    It'd be good to see if they have also replaced the end-of-life (over 5 years ago) idmap_hash ID mapper. 

    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.