• [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



    brenty411

    I've been experiencing this same problem since upgrading to the 6.10 update as well. 😞 Been struggling with this for a month, i'm so embaressed. 

    • Like 1
    Link to comment
    mouseskowitz

    This is a pretty big problem for me as my backup user is the one that is affected. Restarting the server, leaving the domain and rejoining every 7 days fixes some of the issues. However, the share that is owned by the affected user is totally broken at this point. Please get this fixed ASAP!

    • Like 1
    Link to comment
    Frank1940

    Might I suggest that everyone who has these types of issues also provide information on the Windows Server software being used and whether that software is currently updated with the latest patches.

    Link to comment
    mouseskowitz

    I'm using Windows Server 2012R2 fully patched. It is not running on unraid. I have been having the issue since the initial release of 6.10.0.

    Link to comment
    Frank1940

    Unraid version 6.9.2 uses Samba version 4.12.14

    Unraid version 6.10.3 uses Samba version 4.15.7  (Released 28 April 2022)

    Latest stable version of Samba is 4.15.8 (released 28 June 2022)

    Link to comment
    Geoff Bland

    I am using Windows Server 2022 fully patched. 

     

    Windows Server 2022 is running on different physical servers to Unraid. 

    Edited by Geoff Bland
    Link to comment
    CallOneTech

    Windows server 2019 Standard Fully patched (VM on ESXi) over here. This all started somewhere between 6.8.x and now.

    Geoff summarized this issue very well, but I'm more than happy to do any testing or give over any info that will lead to this getting patched.

     

    Hopefully we can finally get an official response to this... I have been rattling cages, resurrecting threads and asking on the discord. So far all I have founds is that everyone using AD is suffering from the same issue and crickets from support. It's a bit frustrating to not at least get a "sucks to suck, deal with it" message after all this time.

    Link to comment
    Frank1940

    Disclaimer:  I am not an expert on Windows Server as I have never had the need to use it.

     

    Having said that I have some experience with SMB.  I began back when Windows for Workgroups was released.  I know just enough to make me dangerous at times.  But I have learned on thing, SMB (and Samba) are a kludge!  And Microsoft (who basically control SMB) has often made changes that break things in Samba.  (or, at least, the way that some of us are using it!)

     

    You also have to understand that LimeTech just adds the standard Samba package to Unraid and generates a smb.conf file that set  it up for most users.   It seems to work for most of us without major problems.  (Well, Windows users are advised to setup a login to the Unraid server to prevent MS from breaking things by insisting on that a secured connection between the Windows client and any server...)

     

    What I propose is that (at least) one of you folks with the problem take a look at the Samba Mailing Lists and see if this problem has been discussed there.  The Link is below:

     

           https://www.samba.org/samba/archives.html

    Edited by Frank1940
    Link to comment
    CallOneTech

    Frank1940, not an attack against you, and that is a fair point, but it feels like something is broken with unraid itself. My primary evidence to support this claim is that the Join and Leave domain buttons in the web GUI stopped working at some point after 6.8.x too.
     
    The only workaround I'm aware of is to shutdown (reboot sometimes doesn't solve it), startup, leave and finally rejoin AD, which seems to refresh whatever keeps spoiling like a jug of milk. However, with the leave & join buttons being broken, you must reboot the server repeatedly to "fix" them.
     
    That means you need to do a restart every 3-6 days and then leave/rejoin your domain to keep it working.
     
    I understand what you're saying, and I'm happy for any efforts to help with this... but MANY folks from the unraid community are IT veterans. They can all see this is clearly a pass-the-buck type play rather than deep diving into the genuine issue inside unraid.
     
    We have all seen it before, anytime you call retail support for anything and everything. The fix is always oddly found by leaving the current support team you're dealing with alone and bugging someone else 🙄
     
    As sad as it is, it seems these days that the only way to get a proper resolution is to shame a person/company into doing what they are supposed to do. It takes a constant pressure campaign that most people don't have the stomach for (and companies know this!). It shouldn't work that way, but it's just how it is.

    I'm 110% positive that if the talented unraid devs got serious about this issue, they could either resolve it or explain it well enough for the Samba devs to make a patch (if that's the root cause).

    • Like 1
    Link to comment
    Geoff Bland

    @Frank & @CallOneTech Thanks for the responses both of you.

     

    I did have a look on the Samba forums and do some Google searching. From my admittedly limited knowledge of Samba this "Failed to convert SID" issue, the only thing I found was a suggestion that it's the way that Samba is configured in relationship to the O/S (User ID ranges). I don't think this is the issue as the UID is a "known" one on Unraid. 

     

    Presumably the Unraid team don't want us digging around in the guts of the Unraid O/S with the command line to try and fix issues like this? Also I assume it is not recommended for users to upgrade third party software that is part of the core Unraid OS - so even if we were able to identify the issue as a Samba one we would not be able to patch it ourselves?

     

    Edited by Geoff Bland
    • Upvote 1
    Link to comment
    Geoff Bland

    It's also worth mentioning that this issue is flooding the syslog with errors which probably is not good for the health of the system, generating over 5MB of log messages per day.

    • Upvote 2
    Link to comment
    dlandon

    Our ability to replicate/troubleshoot these issues is limited because we have limited access to a Windows Server.

     

    If anyone is receptive to a Team VIewer session, we can view what is happening and get more information to see what can be done to solve this issue.

    Link to comment
    Geoff Bland
    4 hours ago, dlandon said:

    Our ability to replicate/troubleshoot these issues is limited because we have limited access to a Windows Server.

     

    If anyone is receptive to a Team VIewer session, we can view what is happening and get more information to see what can be done to solve this issue.

     

    Sure, I can set up a Team Viewer session if it helps you diagnose the issue. Just give me a bit of notice to get things ready...

    Link to comment
    Steve-UnraidUser

    I'm having some kind of SMB related issue too. Tranfers are slow, and in my experience drop out on large file transfers. I've rolled back to my previous version (6.9.2) and things seem to be more stable, and a large file I had issue with transferred first time. I've had this issue on two unraid boxes. On one of them, I resorted to using NFS, which worked without flaw.

    Edited by Steve-UnraidUser
    Link to comment
    dlandon

    There have been several reports of slow SMB copies and issues with copying very large files on Unraid 6.10.  I've just done a quick test of a 160GB file copy from Unraid 6.10 to Unraid 6.11-beta and had 110MB/s copy rate for 25 minutes without any slow downs or other hiccups.  While my quick test is not definitive, and not necessarily directly related to AD file copies, the latest version of samba (4.15.8) may solve your AD issues.

    Link to comment
    CallOneTech

    Dlandon, thank you for jumping in to this thread, it's great to have you here.

     

    It would be awesome if samba (4.15.8) was a magic bullet, but please keep in mind that the slow transfer issue mentioned by Steve-UnraidUser doesn't have anything to do with the original bug that the rest of us are trying to resolve.

     

    I'm sure you noticed that, but I assume your extremely busy and the last thing I want is for us to miss our chance at a fix because the thread got mixed up with multiple bug reports.

     

    Also, thank you Geoff Bland, for offering up the speedy logs and TeamViewer access (when needed).

    Link to comment
    Geoff Bland

    Doing some further testing and I found what looks like another possibly related issue with Samba and Windows AD on UNRAID - creating a new UNRAID user does not work and crashed Samba. 

     

    Steps to reproduce:

     

    1. Create user "test" on Windows AD.

    2. Create same user on Unraid Users page (same user name and password as used for AD). 

     

    @CallOneTech - have you tried creating a new AD user and adding that to UNRAID, do you get the same issue?

     

    This stalls on the UNRAID user page but eventually reverts back to the users page but the new user is not create and is not shown. 

     

    Logs (syslog) show that this caused a crash in the winbind service (daemon) on UNRAID and that this and the Samba service then are restarted.
      

    Jul 24 16:52:30 UNRAID01 emhttpd: shcmd (57994): useradd -g users -d / -s /bin/false -c 'Test user' 'test'
Jul 24 16:52:30 UNRAID01 winbindd[24304]: [2022/07/24 16:52:30.809817,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:30 UNRAID01 winbindd[24304]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:30 UNRAID01 root: useradd: user 'test' already exists
Jul 24 16:52:30 UNRAID01 useradd[21861]: failed adding user 'test', data deleted
Jul 24 16:52:30 UNRAID01 emhttpd: shcmd (57994): exit status: 9
Jul 24 16:52:30 UNRAID01 chpasswd[21864]: pam_unix(chpasswd:chauthtok): user "test" does not exist in /etc/passwd
Jul 24 16:52:30 UNRAID01 emhttpd: Starting services...
Jul 24 16:52:30 UNRAID01 emhttpd: shcmd (58006): /etc/rc.d/rc.samba restart
Jul 24 16:52:30 UNRAID01 nmbd[24278]: [2022/07/24 16:52:30.886364,  0] ../../source3/nmbd/nmbd.c:59(terminate)
Jul 24 16:52:30 UNRAID01 wsdd2[24288]: 'Terminated' signal received.
Jul 24 16:52:30 UNRAID01 nmbd[24278]:   Got SIGTERM: going down...
Jul 24 16:52:30 UNRAID01 winbindd[24291]: [2022/07/24 16:52:30.886429,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
Jul 24 16:52:30 UNRAID01 winbindd[24296]: [2022/07/24 16:52:30.886466,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
Jul 24 16:52:30 UNRAID01 winbindd[24296]:   Got sig[15] terminate (is_parent=0)
Jul 24 16:52:30 UNRAID01 winbindd[24293]: [2022/07/24 16:52:30.886472,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
Jul 24 16:52:30 UNRAID01 winbindd[24291]:   Got sig[15] terminate (is_parent=1)
Jul 24 16:52:30 UNRAID01 winbindd[24304]: [2022/07/24 16:52:30.886518,  0] ../../source3/winbindd/winbindd.c:247(winbindd_sig_term_handler)
Jul 24 16:52:30 UNRAID01 winbindd[24293]:   Got sig[15] terminate (is_parent=0)
Jul 24 16:52:30 UNRAID01 winbindd[24304]:   Got sig[15] terminate (is_parent=0)
Jul 24 16:52:30 UNRAID01 wsdd2[24288]: terminating.
Jul 24 16:52:33 UNRAID01 root: Starting Samba:  /usr/sbin/smbd -D
Jul 24 16:52:33 UNRAID01 smbd[21913]: [2022/07/24 16:52:33.083424,  0] ../../source3/smbd/server.c:1734(main)
Jul 24 16:52:33 UNRAID01 smbd[21913]:   smbd version 4.15.7 started.
Jul 24 16:52:33 UNRAID01 smbd[21913]:   Copyright Andrew Tridgell and the Samba Team 1992-2021
Jul 24 16:52:33 UNRAID01 root:                  /usr/sbin/nmbd -D
Jul 24 16:52:33 UNRAID01 nmbd[21915]: [2022/07/24 16:52:33.113463,  0] ../../source3/nmbd/nmbd.c:901(main)
Jul 24 16:52:33 UNRAID01 nmbd[21915]:   nmbd version 4.15.7 started.
Jul 24 16:52:33 UNRAID01 nmbd[21915]:   Copyright Andrew Tridgell and the Samba Team 1992-2021
Jul 24 16:52:33 UNRAID01 root:                  /usr/sbin/wsdd2 -d 
Jul 24 16:52:33 UNRAID01 wsdd2[21931]: starting.
Jul 24 16:52:33 UNRAID01 root:                  /usr/sbin/winbindd -D
Jul 24 16:52:33 UNRAID01 winbindd[21932]: [2022/07/24 16:52:33.250780,  0] ../../source3/winbindd/winbindd.c:1722(main)
Jul 24 16:52:33 UNRAID01 winbindd[21932]:   winbindd version 4.15.7 started.
Jul 24 16:52:33 UNRAID01 winbindd[21932]:   Copyright Andrew Tridgell and the Samba Team 1992-2021
Jul 24 16:52:33 UNRAID01 winbindd[21934]: [2022/07/24 16:52:33.255697,  0] ../../source3/winbindd/winbindd_cache.c:3085(initialize_winbindd_cache)
Jul 24 16:52:33 UNRAID01 winbindd[21934]:   initialize_winbindd_cache: clearing cache and re-creating with version number 2
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.037017,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.037688,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.037925,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.038164,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.038422,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.045949,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.047362,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.048216,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.048394,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:34 UNRAID01 winbindd[21949]: [2022/07/24 16:52:34.059920,  0] ../../source3/winbindd/idmap_hash/idmap_hash.c:115(idmap_hash_initialize)
Jul 24 16:52:34 UNRAID01 winbindd[21949]:   idmap_hash_initialize: The idmap_hash module is deprecated and should not be used. Please migrate to a different plugin. This module will be removed in a future version of Samba
Jul 24 16:52:39 UNRAID01 emhttpd: shcmd (58012): /etc/rc.d/rc.avahidaemon restart
Jul 24 16:52:39 UNRAID01 root: Stopping Avahi mDNS/DNS-SD Daemon: stopped
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Got SIGTERM, quitting.
Jul 24 16:52:39 UNRAID01 avahi-dnsconfd[24436]: read(): EOF
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface vnet4.IPv6 with address fe80::fc54:ff:fe9e:b40a.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface vnet2.IPv6 with address fe80::fc54:ff:fe10:1e94.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface vnet1.IPv6 with address fe80::fc54:ff:fe08:19ca.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fee4:8c7b.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface veth1c5fb0c.IPv6 with address fe80::5400:3dff:fe48:ee3d.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface vethd3447af.IPv6 with address fe80::ecf0:39ff:feb8:2868.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface docker0.IPv6 with address fe80::42:e3ff:fe58:a277.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.53.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface lo.IPv6 with address ::1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[24427]: avahi-daemon 0.8 exiting.
Jul 24 16:52:39 UNRAID01 root: Starting Avahi mDNS/DNS-SD Daemon:  /usr/sbin/avahi-daemon -D
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214).
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Successfully dropped root privileges.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: avahi-daemon 0.8 starting up.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Successfully called chroot().
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Successfully dropped remaining capabilities.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Loading service file /services/sftp-ssh.service.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Loading service file /services/smb.service.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Loading service file /services/ssh.service.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface vnet4.IPv6 with address fe80::fc54:ff:fe9e:b40a.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface vnet4.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface vnet2.IPv6 with address fe80::fc54:ff:fe10:1e94.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface vnet2.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface vnet1.IPv6 with address fe80::fc54:ff:fe08:19ca.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface vnet1.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fee4:8c7b.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface vnet0.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface veth1c5fb0c.IPv6 with address fe80::5400:3dff:fe48:ee3d.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface veth1c5fb0c.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface vethd3447af.IPv6 with address fe80::ecf0:39ff:feb8:2868.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface vethd3447af.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface virbr0.IPv4 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface docker0.IPv6 with address fe80::42:e3ff:fe58:a277.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface docker0.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface docker0.IPv4 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.53.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface br0.IPv4 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface lo.IPv6 with address ::1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface lo.IPv6 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: New relevant interface lo.IPv4 for mDNS.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Network interface enumeration completed.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::fc54:ff:fe9e:b40a on vnet4.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::fc54:ff:fe10:1e94 on vnet2.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::fc54:ff:fe08:19ca on vnet1.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::fc54:ff:fee4:8c7b on vnet0.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::5400:3dff:fe48:ee3d on veth1c5fb0c.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::ecf0:39ff:feb8:2868 on vethd3447af.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for fe80::42:e3ff:fe58:a277 on docker0.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for 172.17.0.1 on docker0.IPv4.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for 192.168.1.53 on br0.IPv4.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for ::1 on lo.*.
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Registering new address record for 127.0.0.1 on lo.IPv4.
Jul 24 16:52:39 UNRAID01 emhttpd: shcmd (58013): /etc/rc.d/rc.avahidnsconfd restart
Jul 24 16:52:39 UNRAID01 root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped
Jul 24 16:52:39 UNRAID01 root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon:  /usr/sbin/avahi-dnsconfd -D
Jul 24 16:52:39 UNRAID01 avahi-dnsconfd[22089]: Successfully connected to Avahi daemon.
Jul 24 16:52:39 UNRAID01 emhttpd: shcmd (58018): cp /etc/passwd /etc/shadow /var/lib/samba/private/smbpasswd /boot/config
Jul 24 16:52:39 UNRAID01 avahi-daemon[22080]: Server startup complete. Host name is UNRAID01.local. Local service cookie is 2300782782.
Jul 24 16:52:40 UNRAID01 avahi-daemon[22080]: Service "UNRAID01" (/services/ssh.service) successfully established.
Jul 24 16:52:40 UNRAID01 avahi-daemon[22080]: Service "UNRAID01" (/services/smb.service) successfully established.
Jul 24 16:52:40 UNRAID01 avahi-daemon[22080]: Service "UNRAID01" (/services/sftp-ssh.service) successfully established.

     

    Edited by Geoff Bland
    Link to comment
    Geoff Bland

    Just to define my set up.

    I have 2 Windows Server 2022 boxes running as domain controllers. 
    Both also run DNS and DHCP. Both have static IP addresses.
    I have an UNRAID box that was working until I upgraded to 6.2.10. 
    UNRAID box has the 2 Windows Server for DNS.
    UNRAID settings are: 

    • Enable SMB : "Yes (Active Directory)",  
    • No extra Samba configuration.
    • AD Join Status : "Joined", 
    • AD Domain Name (FQDN) : Correct FQDN for my domain, 
    • AD Short Domain Name : Correct short name for my domain, 
    • AD account login : <DOMAIN>\unraid (user "unraid" account is set up as a domain admin). 

     

    I can see that UNRAID is joined to the domain correctly:

      

    root@UNRAID01:~# net ads info
LDAP server: nnn.nnn.nnn.nnn
LDAP server name: ADSERVER.DOMAIN.domain.com
Realm: DOMAIN.DOMAIN.COM
Bind Path: dc=DOMAINSHORTNAME,dc=DOMAIN,dc=COM
LDAP port: 389
Server time: Sun, 24 Jul 2022 17:26:14 BST
KDC server: nnn.nnn.nnn.nnn
Server time offset: 0
Last machine account password change: Mon, 18 Jul 2022 14:24:57 BST

     

    I can see that UNRAID can communicate find with the AD servers to get the user information:

      

    root@UNRAID01:~# net ads user --user=NEWT/unraid --password=*********
Guest
krbtgt
Administrator
unraid
... 
All other users...
...

     

    And yet calling wbinfo for the same users as listed above does not work for all users - those it works for are OK - those it fails for have the problem they cannot access UNRAID.

      

    root@UNRAID01:~# wbinfo -i okuser
okuser:*:2018509906:2018509313:okuser:/home/DOMAINSHORT/okuser:/bin/false
root@UNRAID01:~# wbinfo -i brokenuser
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user brokenuser
root@UNRAID01:~# wbinfo -i unraid
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user unraid

     

    Edited by Geoff Bland
    Link to comment
    CallOneTech

    @Geoff

     

    I gave it a shot because it's been 7 days and 1 hour of uptime and unraid started throwing "check_account: Failed to convert SID" errors right in the middle of watching a show off a share. It seems to happen every 7 days or less, it's like unraid just forgets it joined AD.

     

    I wasn't able to replicate your issue completely, but I did get a ton of errors while adding the user. It threw a bunch of:


    auth3_generate_session_info_pac: winbindd not running - but required as domain member: NT_STATUS_NO_LOGON_SERVERS 

     

    Then it started streaming more of the  "check_account: Failed to convert SID" errors. I assume the Failed to convert SID was triggered by all the active sessions that got knocked off when unraid deiced it couldn't see the domain controller anymore.

     

    It did create the tester user, but it took about 30-40 seconds to create the account (probably due to the background errors).

     

    This is even more annoying for me because my unraid server runs as an esxi vm and usually crashed the esxi host when I reboot it(8 out of 10 times)... but that's a problem for another another day.

     

    I'm currently booting my host back up and going through the worlds most awesome workaround to make my unraid server hopefully work for 7 more days 🤢🤮 

     

    Link to comment
    Brianara3

    Wanted to chime in after coming over from the original forum post. I too have the same issue with Unraid joined to an AD domain. Completely flawless operation on last version of 6.9 then nothing but problems after upgrading to 6.10.2 (and still with 6.10.3). Even downgrading back to 6.9.2 doesn't seem to resolve, so whatever the issue it seems to persist a roll back.

     

    I am also having issues removing/re-joining the domain from Unraid... Clicking the unjoin button does nothing (still says "joined" after reboot), forcibly removing the settings/computer account allows me to re-join and succeeds but I still have the same user lookup and access errors.

     

    Finally, even after dis-joining domain and using local users within Unraid to access SMB shares doesn't seem to apply permissions correctly. I get access denied unless I set the permissions to "public" on my SMB shares even when assigning read or r/w access to users on private and secure config.

     

    Basically... ever since the 6.10 upgrades, SMB is all kinds of broken.

     

    I am running AD on a separate ESXi host using Windows 2019 Server (core edition if it matters). Single domain server, DNS on Unraid pointing to the DC. My Unraid is running on a physical home-built server.

     

    I would provide logs/diags/etc. but at this point I have resorted to rolling back to 6.9.2 and using SMB in workgroup mode with all my internal shares set to public. This of course has "fixed" all of the log errors I had.

    Edited by Brianara3
    • Upvote 1
    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.