Run the command
smbclient
\\
server
\temp, which connects to your server's
/tmp share, to see if you can connect to a file service. You should get the following response:
server% smbclient '\\server\temp'
Server time is Tue May 5 09:49:32 1998 Timezone is UTC-4.0 Password:
smb: \> quit
-
If you get "Get_Hostbyname: Unknown host name," "Connect error: Connection refused," or "Your server software is being unfriendly," see the section "
Section 9.2.5.2, Testing locally with smbclient" for the diagnoses.
-
If you get the message "servertemp: Not enough `\' characters in service," you likely didn't quote the address, so Unix stripped off backslashes. You can also write the command:
smbclient
\\\\
server
\\temp
or:
smbclient //
server/temp
Now, provide your Unix account password to the
Password prompt. If you then get an
smb\> prompt, it worked. Enter
quit, and continue on to "
Section 9.2.5.4, Testing connections with NET USE." If you then get "SMBtconX failed. ERRSRV - ERRinvnetname," the problem can be any of the following:
-
A wrong share name: you may have spelled it wrong, it may be too long, it may be in mixed case, or it may not be available. Check that it's what you expect with testparm (see the section
Section 9.2.4.5.")
-
security
=
share, in which you may have to add
-U your_account to the
smbclient command, or know the password of a Unix account named temp.
-
An erroneous username.
-
An erroneous password.
-
An
invalid
users or
valid
users option in your
smb.conf file that doesn't allow your account to connect. Recheck with
testparm
smb.conf
your_hostname your_ip_address (see "
Section 9.2.4.5").
-
A
valid
hosts option that doesn't include the server, or an
invalid
hosts option that does. Also test this with
testparm.
-
A problem in authentication, such as if shadow passwords or the PAM (Password Authentication Module) is used on the server, but Samba is not compiled to use it. This is rare, but occasionally happens when a SunOS 4 Samba binary (no shadow passwords) is run without recompilation on a Solaris system (with shadow passwords).
-
The
encrypted
passwords
=
yes option in the configuration file, but no password for your account in the
smbpasswd file.
-
You have a null password entry, either in Unix
/etc/passwd or in the
smbpasswd file.
-
You are connecting to
[temp], and you do not have the
guest
ok
=
yes option in the
[temp] section of the
smb.conf file.
-
You are connecting to
[temp] before connecting to your home directory, and your guest account isn't set up correctly. If you can connect to your home directory and then connect to
[temp], that's the problem. See Chapter 2 for more information on creating a basic Samba configuration file.
A bad guest account will also prevent you from printing or browsing until after you've logged in to your home directory.
There is one more reason for this failure that has nothing at all to do with passwords: the
path
= line in your
smb.conf file may point somewhere that doesn't exist. This will not be diagnosed by
testparm, and most SMB clients can't tell it from other types of bad user accounts. You will have to check it manually.
Once you have connected to
[temp] successfully, repeat the test, this time logging in to your home directory (e.g., map network drive
server
\davecb) looking for failures in doing that. If you have to change anything to get that to work, re-test
[temp] again afterwards.
