harpesichord

I have been having the same problems as you all, I had a single user that was giving the same error message while my other users would authenticate without issue. I found a solution that at least seems to fix the issue for me, after doing these steps the user can authenticate and I don't see the error message. Whether or not the issue will return I don't know. I found the following post that someone had made about samba back in January. From that post a user stated that the smb.conf file should contain the following lines. The one generated by unraid did not match. (https://www.spinics.net/lists/samba/msg173243.html ) # Where mydomain.com matches your realm option idmap config mydomain.com : range = 100000-999999 idmap config mydomain.com : backend = rid idmap config * : range = 3001-7999 idmap config * : backend = tdb I added this to the "/boot/config/smb-extra.conf" file, but you can also add it in the UI under "Samba extra configuration". From that post it contains a link to this page which contains more info about this change https://wiki.samba.org/index.php/Idmap_config_rid I suppose at this point you could reboot the server and it should be resolved, but I ended up just deleting the samba cache files. I followed instructions from this post and changed it slightly for unraid. https://serverfault.com/questions/476086/samba-winbind-user-resolution /etc/rc.d/rc.samba stop rm -rf /var/lib/samba mkdir -p /var/lib/samba/private rm -rf /var/cache/samba /etc/rc.d/rc.samba restart After doing this my problem user was able to login. Just to be sure I rebooted the server and was still able to authenticate without issues. I don't know if this will fix everyone's issues but its worth a try. I also don't know why these idmap options are now required but only required for certain users. There is probably some more information out there about this, but I don't feel like investigating anymore tonight. I did a quick test just to verify this wasn't a fluke by removing the idmap options and restarting samba, and the user immediately failed. Redoing the steps above fixed it again.