See BROWSING.txt for more information on browsing. Browsing.txt can also be found in the docs directory of the Samba source.
If your GUI client does not permit you to select non-browsable servers, you may need to do so on the command line. For example, under Lan Manager you might connect to the above service as disk drive M: thusly:
net use M: \\mary\fred
If you check what files are not showing up, you will note that they are files which contain upper case letters or which are otherwise not DOS-compatible (ie, they are not legal DOS filenames for some reason).
The Samba server can be configured either to ignore such files completely, or to present them to the client in "mangled" form. If you are not seeing the files at all, the Samba server has most likely been configured to ignore them. Consult the man page smb.conf(5) for details of how to change this - the parameter you need to set is "mangled names = yes".
This indicates one of three things: You supplied an incorrect server name, the underlying TCP/IP layer is not working correctly, or the name you specified cannot be resolved.
After carefully checking that the name you typed is the name you should have typed, try doing things like pinging a host or telnetting to somewhere on your network to see if TCP/IP is functioning OK. If it is, the problem is most likely name resolution.
If your client has a facility to do so, hardcode a mapping between the hosts IP and the name you want to use. For example, with Man Manager or Windows for Workgroups you would put a suitable entry in the file LMHOSTS. If this works, the problem is in the communication between your client and the netbios name server. If it does not work, then there is something fundamental wrong with your naming and the solution is beyond the scope of this document.
If you do not have any server on your subnet supplying netbios name resolution, hardcoded mappings are your only option. If you DO have a netbios name server running (such as the Samba suite's nmbd program), the problem probably lies in the way it is set up. Refer to Section Two of this FAQ for more ideas.
By the way, remember to REMOVE the hardcoded mapping before further tests :-)
This message indicates that your client CAN locate the specified server, which is a good start, but that it cannot find a service of the name you gave.
The first step is to check the exact name of the service you are trying to connect to (consult your system administrator). Assuming it exists and you specified it correctly (read your client's doco on how to specify a service name correctly), read on:
Nothing is wrong - Samba does not implement the primary domain name controller stuff for several reasons, including the fact that the whole concept of a primary domain controller and "logging in to a network" doesn't fit well with clients possibly running on multiuser machines (such as users of smbclient under Unix). Having said that, several developers are working hard on building it in to the next major version of Samba. If you can contribute, send a message to samba-bugs@samba.anu.edu.au !
Seeing this message should not affect your ability to mount redirected disks and printers, which is really what all this is about.
For many clients (including Windows for Workgroups and Lan Manager), setting the domain to STANDALONE at least gets rid of the message.
Make sure that the specified print command for the service you are connecting to is correct and that it has a fully-qualified path (eg., use "/usr/bin/lpr" rather than just "lpr").
Make sure that the spool directory specified for the service is writable by the user connected to the service. In particular the user "nobody" often has problems with printing, even if it worked with an earlier version of Samba. Try creating another guest user other than "nobody".
Make sure that the user specified in the service is permitted to use the printer.
Check the debug log produced by smbd. Search for the printer name and see if the log turns up any clues. Note that error messages to do with a service ipc$ are meaningless - they relate to the way the client attempts to retrieve status information when using the LANMAN1 protocol.
If using WfWg then you need to set the default protocol to TCP/IP, not Netbeui. This is a WfWg bug.
If using the Lanman1 protocol (the default) then try switching to coreplus. Also not that print status error messages don't mean printing won't work. The print status is received by a different mechanism.
There are numerous possible reasons for this, but one MAJOR possibility is that your software uses locking. Make sure you are using Samba 1.6.11 or later. It may also be possible to work around the problem by setting "locking=no" in the Samba configuration file for the service the software is installed on. This should be regarded as a strictly temporary solution.
In earlier Samba versions there were some difficulties with the very latest Microsoft products, particularly Excel 5 and Word for Windows 6. These should have all been solved. If not then please let Andrew Tridgell know via email at samba-bugs@samba.anu.edu.au.
OR My client reports the default setting, eg. "Samba 1.9.15p4", instead of what I have changed it to in the smb.conf file.
You need to use the -C option in nmbd. The "server string" affects what smbd puts out and -C affects what nmbd puts out.
Current versions of Samba (1.9.16 +) have combined these options into the "server string" field of smb.conf, -C for nmbd is now obsolete.
Your guest account is probably invalid for some reason. Samba uses the guest account for browsing in smbd. Check that your guest account is valid.
See also 'guest account' in smb.conf man page.
This can have several causes. It might be because you are using a uid or gid of 65535 or -1. This is a VERY bad idea, and is a big security hole. Check carefully in your /etc/passwd file and make sure that no user has uid 65535 or -1. Especially check the "nobody" user, as many broken systems are shipped with nobody setup with a uid of 65535.
It might also mean that your OS has a trapdoor uid/gid system :-)
This means that once a process changes effective uid from root to another user it can't go back to root. Unfortunately Samba relies on being able to change effective uid from root to non-root and back again to implement its security policy. If your OS has a trapdoor uid system this won't work, and several things in Samba may break. Less things will break if you use user or server level security instead of the default share level security, but you may still strike problems.
The problems don't give rise to any security holes, so don't panic, but it does mean some of Samba's capabilities will be unavailable. In particular you will not be able to connect to the Samba server as two different uids at once. This may happen if you try to print as a "guest" while accessing a share as a normal user. It may also affect your ability to list the available shares as this is normally done as the guest user.
Complain to your OS vendor and ask them to fix their system.
Note: the reason why 65535 is a VERY bad choice of uid and gid is that it casts to -1 as a uid, and the setreuid() system call ignores (with no error) uid changes to -1. This means any daemon attempting to run as uid 65535 will actually run as root. This is not good!