| Summary: | Authentication fails when netbios/hostname is longer than MAX_NETBIOSNAME_LEN-1 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
| Component: | samba | Assignee: | Guenther Deschner <gdeschner> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | abokovoy, asn, gdeschner, jlayton, madam, martin, sbose, ssorce |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | samba-4.1.15-1.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-01-17 23:56:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Harald Reindl
2014-12-18 12:48:44 UTC
P.S: yes i know that i gave karma after upgraded the first machines without any troubles except two remote servers while the last one failed Have you upgraded libwbclient as well ? surely Dec 18 10:32:48 Installed: 2:libwbclient-4.1.14-1.fc20.x86_64 Dec 18 10:32:49 Installed: 2:samba-libs-4.1.14-1.fc20.x86_64 Dec 18 10:32:49 Installed: 2:samba-common-4.1.14-1.fc20.x86_64 Dec 18 10:32:49 Installed: 2:libsmbclient-4.1.14-1.fc20.x86_64 Dec 18 10:32:49 Installed: 2:samba-client-4.1.14-1.fc20.x86_64 Dec 18 10:32:50 Installed: 2:samba-4.1.14-1.fc20.x86_64 Dec 18 13:31:52 Installed: 2:libwbclient-4.1.12-5.fc20.x86_64 Dec 18 13:31:53 Installed: 2:samba-libs-4.1.12-5.fc20.x86_64 Dec 18 13:31:54 Installed: 2:samba-common-4.1.12-5.fc20.x86_64 Dec 18 13:31:54 Installed: 2:libsmbclient-4.1.12-5.fc20.x86_64 Dec 18 13:31:54 Installed: 2:samba-client-4.1.12-5.fc20.x86_64 Dec 18 13:31:54 Installed: 2:samba-4.1.12-5.fc20.x86_64 Dec 18 13:33:09 Updated: 2:libwbclient-4.1.14-1.fc20.x86_64 Dec 18 13:33:11 Updated: 2:samba-libs-4.1.14-1.fc20.x86_64 Dec 18 13:33:11 Updated: 2:samba-common-4.1.14-1.fc20.x86_64 Dec 18 13:33:11 Updated: 2:libsmbclient-4.1.14-1.fc20.x86_64 Dec 18 13:33:11 Updated: 2:samba-client-4.1.14-1.fc20.x86_64 Dec 18 13:33:11 Updated: 2:samba-4.1.14-1.fc20.x86_64 Dec 18 13:34:04 Installed: 2:libwbclient-4.1.12-5.fc20.x86_64 Dec 18 13:34:05 Installed: 2:samba-libs-4.1.12-5.fc20.x86_64 Dec 18 13:34:06 Installed: 2:samba-common-4.1.12-5.fc20.x86_64 Dec 18 13:34:06 Installed: 2:libsmbclient-4.1.12-5.fc20.x86_64 Dec 18 13:34:06 Installed: 2:samba-client-4.1.12-5.fc20.x86_64 Dec 18 13:34:06 Installed: 2:samba-4.1.12-5.fc20.x86_64 Is an old smbd still running by chance? i.e. unless you are not already doing so: could you make sure the upgrade process incorporates the following steps: - stop the samba services - make sure no smbd / winbindd / nmbd process is running - upgrade the packages to 4.1.14 - check symbol versions with "nm /lib64/libwbclient.so.0" and look out for occurrences of 4.1.12 - start samba - try login If the same happens as above, or if the nm check shows 4.1.12 then we have a problem with the binaries/libraries in the pkg. But since the upgrade works nicely on other servers, I rather think there is a more likely a problem with the starting/stopping the daemons during upgrade. Michael nm: /lib64/libwbclient.so.0: no symbols i completly stopped samba multiple times and restarted it at least 30 times by trying to play around with smb.conf (use one from other working machines) and raise/lower logging on the affected machine, deleted *anything* below /var/lib/samba/ and added a new user after that with "smbpasswd" after 3 hours i gave up, downgraded and all worked with the new password-database as well as with the backups containing the existing users and after another update it pretended again "NT_STATUS_NO_SUCH_USER" which is a different message than "NT_STATUS_WRONG_PASSWORD" i really have no clue what's going on there nor how it is possible that this affects only one machine but in fact "samba-4.1.12-5.fc20.x86_64" don't have that issue Please try objdump -T /lib64/libwbclient.so.0 | grep SAMBA instead of nm. For me it looks that the update did not remove the old version of the library. Pleae note that in 4.1.14 /lib/libwbclient.* is manages by the alternatives tool which afaik does not remove existing files. After the update /lib64/libwbclient.so.0.11 should be a link to /etc/alternatives/... If it is a file it is most probably the old version and yum/rpm was not able to remove it. * it is a symlink * i removed the phyiscal file before update again * Dec 18 17:51:35 south smbd: /usr/sbin/smbd: error while loading shared libraries: libwbclient.so.0: cannot open shared object file: No such file or directory * so the upgrade path is borked because smbd restarts in the middle fof the yum transaction * FRANKLY THAT is why i hate this damned automatic restarts because i am the once who decides when to restart services in case of deploy updates to 30 machines * i really don't get why we start with alternatives crap in case of libraries in any case - on that machine 4.1.4 don't work NT_STATUS_NO_SUCH_USER downgraded again before users kill me and all is fine _____________________________________________ that crash happens exatly *once* due upgrade Dec 18 17:47:56 localhost smbd: /usr/sbin/smbd: error while loading shared libraries: libwbclient.so.0: cannot open shared object file: No such file or directory Dec 18 17:47:56 localhost systemd: smb.service: control process exited, code=exited status=127 Dec 18 17:47:56 localhost systemd: Failed to start Samba SMB Daemon. 0000000000000000 DF *UND* 0000000000000000 SAMBA_4.1.14 winbindd_free_response 0000000000000000 DF *UND* 0000000000000000 SAMBA_4.1.14 winbindd_request_response 0000000000000000 DF *UND* 0000000000000000 SAMBA_4.1.14 winbindd_priv_request_response I seem to have this problem as well. I also have several machines and only one is affected. The problem started as soon as the 4.1.14 update was installed. An active connection from a Windows machine stopped working and I could not authenticate it again. They all have fairly basic SMB configurations - standalone servers with a small number of shares and users. The machines that work are older installs and are still using an smbpasswd file. The affected machine will not accept logins. I get NT_STATUS_NO_SUCH_USER. The user is in the tdbsam database and prior to the update everything was working. The library file mentioned above is a symlink. I have verified the samba RPMS and they are ok. I have spent several hours troubleshooting and have not identified the problem. Local connection fails: smbclient //localhost/video -U martin Enter martin's password: ********* session setup failed: NT_STATUS_LOGON_FAILURE Samba log snippet: [2015/01/09 10:19:44.982150, 3] ../source3/auth/auth.c:177(auth_check_ntlm_password) check_ntlm_password: Checking password for unmapped user [MYGROUP]\[martin]@[ANALYTICAL-ENGINE] with the new password interface [2015/01/09 10:19:44.982187, 3] ../source3/auth/auth.c:180(auth_check_ntlm_password) check_ntlm_password: mapped user is: [ANALYTICAL-ENGINE]\[martin]@[ANALYTICAL-ENGINE] [2015/01/09 10:19:44.982221, 2] ../source3/auth/auth.c:288(auth_check_ntlm_password) check_ntlm_password: Authentication for user [martin] -> [martin] FAILED with error NT_STATUS_NO_SUCH_USER [2015/01/09 10:19:44.982266, 2] ../auth/gensec/spnego.c:743(gensec_spnego_server_negTokenTarg) SPNEGO login failed: NT_STATUS_NO_SUCH_USER pdbedit output: Module 'tdbsam' loaded Unix username: martin NT username: Account Flags: [U ] User SID: S-1-5-21-807222276-2518046738-2387355048-1005 Primary Group SID: S-1-5-21-807222276-2518046738-2387355048-513 Full Name: Martin Home Directory: \\analytical-engine\martin HomeDir Drive: Logon Script: Profile Path: \\analytical-engine\martin\profile Domain: Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Wed, 06 Feb 2036 15:06:39 GMT Kickoff time: Wed, 06 Feb 2036 15:06:39 GMT Password last set: Fri, 09 Jan 2015 09:27:22 GMT Password can change: Fri, 09 Jan 2015 09:27:22 GMT Password must change: never Last bad password : 0 Bad password count : 0 Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF # ls -l /lib64/libwbclient.so.0.11 lrwxrwxrwx. 1 root root 40 Jan 8 11:33 /lib64/libwbclient.so.0.11 -> /etc/alternatives/libwbclient.so.0.11-64 # rpm --verify samba samba-common samba-libs libwbclient S.5....T. c /etc/samba/smb.conf I think the answer is here: https://bbs.archlinux.org/viewtopic.php?id=190592 4.1.14 appears to have changed the way long server names are handled. Previously they were not truncated, now they are. This causes a check for local name to fail. It's visible with auth logging set to 10. I have manually set a short netbios name in the config and the shares are now accessible. indeed - the servername in smb.conf had 16 chars, changed to one with 5 chars and login works also with 4.1.14 - Aaaaaargh I've proposed a patch to fix this issue upstream. samba-4.1.15-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/samba-4.1.15-1.fc20 samba-4.1.15-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/samba-4.1.15-1.fc21 Package samba-4.1.15-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing samba-4.1.15-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0701/samba-4.1.15-1.fc20 then log in and leave karma (feedback). samba-4.1.15-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. samba-4.1.15-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |