Samba - release 3.x

Introduction ─ foreword
I have been working with Samba in the past 10 years, and I appreciate the use of Samba -- in 99% of the cases it works effectively well; in 1% of the cases it doesn't work, there are nice workarounds that are easily solvable.
In the first step, Samba configuration can be quite frustrating, especially when you pick old Windowzed versions like ®Windows95. From WindowsXP onwards, the NetBIOS protocol runs swiftly through your favorite samba distro. Samba, since the one released -- for instance -- on RedHat 7.2, is absolutely a stable product. Even better: it's free, and open-source, what could you want more?

Is Samba running, where?
If you have an upgraded Samba installed, you can try:

tr \\0 " " < /proc/`cat /usr/local/samba/var/locks/smbd.pid`/cmdline | xargs -n1

If the smbd.pid is not in that path, you can use the command:

locate pid | grep pid$ | grep samba

In a Debian Sarge version, you will see: /var/run/samba/smbd.pid, and /var/run/samba/nmbd.pid. What is this?
Smbd is actually the Samba server, listening:

% netstat -l -t -n | grep 139
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN

This is also known as the NETBIOS session service, or in simple words, the NetBIOS server provided by the Samba daemon.
Remaining question is: what is 'nmbd' ? This is listening at "0 0.0.0.0:445", known as the "microsoft-ds", or just the Microsoft Active Directory.
Try the following command:

netstat -l -t -n -p | grep mbd

...to prove this is also served by the same Samba daemon, not nmbd. If you do:

netstat -l -p | grep nmbd

udp 0 0 10.0.0.8:netbios-ns *:* 2303/nmbd
udp 0 0 *:netbios-ns *:* 2303/nmbd
udp 0 0 10.0.0.8:netbios-dgm *:* 2303/nmbd
udp 0 0 *:netbios-dgm *:* 2303/nmbd

the answer is nearly there: UDP ports 137 and 138 are served by nmbd. Next question is, for what? I do not know. Either way, you can access all files by just using smbd.

What happens to a Windows client if the Samba server is stopped?
Supose M: is a share by your Samba server.
Stopping the Samba server will lead to:

M:\>dir
Configuration information could not be read from the domain controller,
either because the machine is unavailable, or access has been denied.

You can also do vice-versa: you can have use your Windows share from your Linux/Unix server. This is made possible through smbmount, as long your Kernel is prepared to use it.

# example
% grep -i smb /boot/config-2.4.26-skas-8
CONFIG_SMB_FS=y

You make a mount of remote share (say, at host luisa, having the share name D):

% mount -t smbfs //luisa/D /mnt/test -o username=administrator
Password: ********

You can surely put the option "password=xyz", being xyz the password of Windows user administrator.
This works nicely. You can see on the local mount (in the example above, /mnt/test) on your Linux/Unix machine.
Great.
There is a slight flaw for which I do not know the root-cause: if you switch off your Windows host (in the example, luisa), the Kernel sometimes hangs. I have make this very test with dozens of Kernels (including 2.6.x) and Samba versions, including samba-3.0.24, and I got the same result -- I wasn't able to switch off my Linux host. This is not a problem if you unmount the remote share before switching of the PC (PC here is luisa). Stopping Samba may work sometimes.

Protecting Samba shares
Samba is great, what now? You would be suicidal if you would provide a public Samba share. Lot's of security issues are not covered yet. A nice idea I am wondering about, is to secure your public share by using a nice ssh-tunnel, and a local smb-proxy for the purpose of making the real NetBIOS connection to the local Samba daemon. This is my future work.