This will make /tmp on the server available as a Samba share over TCP/IP. The use of security = user and map to guest allows guest shares to operate similarly to the deprecated security = share mode that existing Samba administrators may be familiar with.
A user with a Windows username that Samba does not recognise will not need to provide credentials to access the share, and they will be authenticated as the guest user. Any files they write there will have their user and group ID set to 'nobody'. However, if the username is known to Samba, then the user will be prompted for their password. This might seem weird, but it is consistent with the way Windows works.
Start the Samba daemon, smbd, to make this share accessible on Windows. To access it, use Windows Explorer to browse to the Samba server (use either its name or IP address).
There is another networking protocol that has long been associated with Windows networking and, therefore, an integral part of the Samba suite: NetBIOS. These days, NetBIOS generally refers to the NetBIOS over TCP/IP protocol, which is considered a legacy protocol. It offers name resolution, file and printer sharing with devices that do not have DNS capabilities. It used to be essential in a Windows network, but is no longer necessary unless older versions of Windows are involved, but you still need it if you want clients running operating systems prior to Windows 2000 to be able to access your shares.
If you don't want NetBIOS, then the following additions to the [global] section of smb.conf will make this explicit:
[global]
# disable NetBIOS
disable netbios = yes
smb ports = 445
Should you need it, however, enabling NetBIOS requires other changes to smb.conf:
[global]
# NetBIOS identification
workgroup = WORKGROUP
netbios name = MYHOST
wins support = Yes
This tells Samba to use NetBIOS to make itself known on the Windows network in its default workgroup (Windows machines default to a workgroup called WORKGROUP) and to act as a WINS server. The NetBIOS name is the equivalent of a host name - it does not need to be the same as the host name, but that is customary.
WINS is the Windows Internet Name Service, Microsoft's implementation of a NetBIOS Name Service, and it provides a similar service for NetBIOS names that a DNS provides for domain names (mapping host names to network addresses). Name lookups will resolve without a WINS server, but only within the local subnet - if a client is unable to resolve a NetBIOS name using a WINS server then it will resort to broadcasting "where are you?" messages on the network.
This is one reason why sysadmins hate NetBIOS, and why you should disable it unless you really need it. You can also read plenty on the internet on how NetBIOS is insecure.
If you need NetBIOS, then the final piece required to support it is to run Samba's nmbd process as well as its smbd process. It is nmbd that provides the NetBIOS naming and WINS services.
It's worth understanding how connections are made from the client side. Prior to Windows 2000, connections were only made via NetBIOS, which connects to port 139 on the server. Starting with Windows 2000, connections are made using both NetBIOS and TCP/IP, the latter connecting to port 445 on the server. The client closes its NetBIOS connection on port 139 if the server responds to the TCP/IP connection.
As you would expect, shares can be configured so that authentication is required to access them. This requires a database of users to authenticate. This is the first area where the Active Directory setup differs from the classic setup.
