[Samba] Fatal Samba bug? Why can't anyone answer this question?

Michael Heydon michaelh at jaswin.com.au
Mon Mar 12 07:20:24 GMT 2007

Ron House wrote:
> Perhaps this is this a fatal bug in samba if no one knows how to fix 
> it. Below is my original question:
In general people (developers especially) aren't terribly likely to 
respond to anything that blames a a bug and then proceeds to describe a 
problem that sounds more like a configuration error than anything else

> The problem: Machines B and C allow users to mount samba shares, but 
> machines A and D don't. I get:
> smbmount //spk/homes ~/mnt
> Password:
> 3573: tree connect failed: ERRSRV - ERRbadpw (Bad password - 
> name/password pair in a Tree Connect or Session Setup are invalid.)
> SMB connection failed
 From this I assume all 4 machines are attempting to mount the same 
share off a single server? First off, afaik smb is depreciated, use 
cifs. Don't call smbmount directly, use mount -t smb (or mount -t cifs). 
Neither of those are likely to cause your problem but thats how its done

> client use spnego=no
This could be your problem. Why do you have this line? Do you really 
need it?

Alot of the settings in your config file are contraditory, depreciated, 
or just plain wrong. Since you only talk about these machines as being 
clients I won't go into the details since they aren't really important, 
however I would suggest that for the most part samba has pretty good 
defaults and you should only be defining something in the config file if 
you understand it and know that you need it.

Aside from the line above the config file you posted doesn't appear to 
have much info related to acting as a client. Is the server a samba box? 
can you provide the config from that?
> A few more facts: the user attempting to mount the share has the same 
> uid and password on all machines, so unless there is some other 
> password somewhere in the samba system, it _is_ getting the right 
> password. Furthermore, all machines can ssh and scp to/from all others.
Samba doesn't use the unix password database, it uses its own storage 
which in your case is set to a tdbsam database. SSH and scp are not 
valid tests since they only test the unix passwords. Based on the error 
returned my guess is that it _isn't_ getting the right password.
> To make matters worse, I can't find any error logs. A recursive grep 
> on /var/log for samba only finds the startup messages from when the 
> machine is turned on.
Your log files are stored as per the "log file" setting in your 
smb.conf, you may have to create the directory. Samba rarely (if ever) 
writes it's own name to it's log files (who is going to be writing to a 
samba log file but samba?) try searching for smb as samba will record 
which daemon (smbd or nmbd) is producing the errors.
> BTW, when changing smb.conf, what is the recommended way to restart 
> the samba server with the new settings? The man pages aren't too clear 
> on that.

       The  configuration  file, and any files that it includes, are 
       cally reloaded every minute, if they change. You can force a 
reload  by
       sending  a  SIGHUP to the server. Reloading the configuration 
file will
       not affect connections to any  service  that  is  already  
       Either  the  user  will  have  to  disconnect from the service, 
or smbd
       killed and restarted.

Which bit is unclear? The user has to disconnect using for example "net 
use * /delete" and reconnect or you have to kill the smbd process on the 
server. Different distros will have their own way of doing this or you 
can use a combination of smbstatus, ps, kill and killall.

Basically if you can provide the config file from the server it would go 
along way towards solving your problems.

-- Michael Heydon

More information about the samba mailing list