Bug 1175710

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.