Created attachment 13104 [details] log10 of when working A Linux Domain member set up as per the release notes will show the correct Unix home dir & login shell for a user: getent passwd rowland rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash Wait a short while and then run the command again: getent passwd rowland rowland:*:10000:10000::/home/SAMDOM/rowland:/bin/false You then need to restart winbindd to make it work again, 'net cache flush' doesn't seem to work.
Created attachment 13105 [details] log10 of when not working
Created attachment 13106 [details] smb.conf
I don't see a difference, both log files have the same md5sum of 5c8c118b5b030a002b12aacb56ca6c75. What is your perceived difference in both files?
Created attachment 13108 [details] The real one where it is not working OOPS, sorry, bit ham fisted there, sent same file twice
Created attachment 13313 [details] log.winbindd from an nss info failure case
Created attachment 13314 [details] log.winbindd-idmap from an nss info failure case I'm hitting this as well. It looks like Rowland and I are both getting NTSTATUS 0xF2000051 from GETNSSINFO. In both cases it's falling back to the templated info. Curiously, I can't find any known LDAP (facility 0xF2) errors that match code 0x51 in 4.6.5.
I'm not seeing any traffic on the DC (also Samba, also 4.6.x) for this user info request, so it may be hitting the cache. However, netsamlogon_cache doesn't contain the NSS/rfc2307 information. Should it? Are we erroneously falling back to incomplete cached information?
I am hitting this bug on my home environment too. I upgraded from 4.5.10 to 4.6.5, and after the upgrade wbinfo is also ignoring the loginShell and unixHomeDirectory on my domain member. With this version, restarting winbindd, flushing the cache or even manually removing cache files in /var/lib/samba had no effect. Downgrading back samba, smbclient and libwbclient back to 4.5.10 solved the issue with wbinfo -i once again reporting the correct data.
David, If you're not getting any NSS info from the DC, even after restarting winbindd, that sounds like a different issue than 12720. Did you switch to the new "idmap config DOMAIN: unix_*" config keys? If not, please refer to the 4.5->4.6 transition notes.
Sorry, I explained myself terribly. I do get NSS info, it is just the unixHomeDir and the loginShell the ones that now are not being overridden with the AD attributes. I created a sample user, I hope this explains the issue. This is with Samba 4.5.10: getent passwd sambatestuser sambatestuser:*:11118:10513:sambaTestUser:/tmp/sambaTestUser:/sbin/nologin And this is with Samba 4.6.: getent passwd sambatestuser sambatestuser:*:11118:10513::/home/sambatestuser:/bin/bash My samba config file sets bash as the template default shell: template shell = /bin/bash template homedir = /home/%U Everything else keeps working. I only realized this issue because for my user the default shell is zsh, not bash. Only when troubleshooting that I found that for some of the users I configured with /sbin/nologin as the loginShell I was now seeing bash. The list of users and groups, and specially the idmap values are still ok. However, contrary to Rowland, restarting winbind and flushing the cache will have no effect, at no point using samba 4.6.5 I have seen the AD values being displayed for loginShell and unixHomeDir, only the template ones.
Created attachment 13384 [details] Patch for 4.6 and 4.7 cherry-picked from master
(In reply to Ralph Böhme from comment #11) > Created attachment 13384 [details] > Patch for 4.6 and 4.7 cherry-picked from master Ralph, is that really for the right bug for this patch?
(In reply to Volker Lendecke from comment #12) -v please. :) Adding the retry logic to query-user looked reasonable. However, I haven't analyzed the traces attached to this bugreport.
(In reply to Volker Lendecke from comment #12) Volker, These logs point to a transient loss of connection to the DC. This connection loss is exacerbated by the NSS info missing from the winbind cache. I posit that these connection failures have existed for a while and in 4.5 and below the cache was covering until the connection was reestablished. I think this patch is the right one to pull in for the 4.6 release series since it addresses the immediate issue. I'm not sure a more broadly-scoped change to user caching would be as safe.
Pushed to autobuild-v4-{6,7}-test.
(In reply to Karolin Seeger from comment #15) Pushed to both branches. Closing out bug report. Thanks!