CSUF LogoCSUF Site Navigation

F12 Network/Filesystem Services & Applications Samba

Department of Electrical and Computer Engineering
Associate Professor Gregory R. Kriehn
F12 Samba Server for Windows

Samba is a Windows file server for Unix/Linux operating systems that implements the Server Message Block (SMB) protocol. The protocol is sometimes also referred to as the Common Internet File System (CIFS), and the software suite consists of two main daemons: smbd and nmbd.  smbd provides file and print services to SMB clients, such as Windows 95/98, Windows NT and XP, Windows for Workgroups, etc. The nmbd daemon provides NetBIOS nameservice and browsing support. In other words, Samba allows a user on a Windows client to access a Unix/Linux filesystem. This includes support for opening and transferring files seamlessly back and forth between the two systems, re-naming files, deleting or creating them, executing files, etc. It is an extremely useful suite of tools, as it basically allows a way for a Unix-based filesystem to play nicely with a Windows-based filesystem. A holy grail between Windows and Linux, even. For me, this means that I can store all of my Windows-based files (circuit simulations, test problems generated by certain programs, student data files, etc.) on my Linux server and maintain a centralized location where everything is accessed from. Furthermore, when setup properly, I can access the Linux filesystem over an ethernet connection as well as through my wireless connection on campus. So when I'm teaching in class and am on the Windows partition of my laptop, I can still access my simulation files located on the server here. It's all fine and dandy, and gives me warm fuzzies every time I think about it. But there's only one problem...

Unlike Apache, setting up Samba is a never ending nightmare. If Apache takes 5 minutes to setup, Samba always seems to take hours 
which, every now an then, transforms into days. :( I don't know who exactly is to blame. Samba is extremely complicated, to be sure. So part of it may be me. And when it works, it works flawlessly. But at the same time, the documentation over at www.samba.org always seems to be a bit lacking with respect to the answers that I need, and configuring the package is convoluted. It's a far cry from Apache. So when I setup Samba in Fedora Core 6, imagine my unending happiness when, for the first time ever, I got it up and running in under an hour, and it did not break two days later (which is what happened to me in Fedora Core 5). For Fedora 12, installation has been smooth as well.  Perhaps I'm just getting better at configuring the package.

Configure the firewall and selinux

Before you even think about starting, see the Firewall and SELinux pages to make sure that they are both configured properly. Please take note that I am not using winbind, and thus Port 445 remains closed. Again, see the firewall page for details.

Configure the /etc/samba/smb.conf Configuration File

The master configuration file for samba is /etc/samba/smb.conf. We are going to first copy it over to /etc/samba/smb.conf.master, because every time a connection is made using Samba, the entire smb.conf file is read. Therefore, we'll strip all of the comments from smb.conf.master and create a new, compact smb.conf file for quicker access time.
~> sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.master
Next, edit the smb.conf.master file. I am not going to go into a lot of details here, other than to say that I am using user-level security, opposed to share or domain security. The reason for this is that I want to have access to my home directory, but am going to require a valid username and password while logging in from Windows before I will allow access to my Linux filesystem.  

Scroll through the file, and set the various options:

   workgroup = [USER]
   server string = Samba Server Version %v

   interfaces = lo eth0 xxx.xxx.255.255
   hosts allow = xxx.xxx. 127.

   log file = /var/log/samba/%m.log
   max log size = 50

   security = user
   passdb backend = tdbsam

   local master = yes
   os level = 33
   domain master = yes
   preferred master = yes

   wins support = yes
   dns proxy = no

   load printers = yes
   cups options = raw
   printcap name = /etc/printcap
   printing = cups

   comment = [Insert Title Here]
   browseable = no
   writeable = yes

   comment = All Printers
   path = /usr/spool/samba
   browseable = No
   guest ok = No
   writable = No
   printable = Yes
Depending on how I connect to the internet with my laptop, the computer can either be on a local ECE subnet, or a college-wide subnet. Therefore, I have set the "hosts allow" and "remote announce" options to allow for either of these two cases, (in addition to the loopback interface). As an example, if the the two subnets were on 100.200.300.xxx and 100.200.400.xxx, then setting hosts allow to 100.200. allows me to connect to the Samba server from either subnet. Remote announcement of the Samba server then needs to occur over to announce its existence over every IP address across over both subnets as well. That way, when I'm on the laptop and connected to Windows, I'll be able to find the Samba server automatically wherever I'm at.

The backend for the password database used to be smbpasswd, but according to the release notes for Samba 3.0.23a, and the latest Samba documentation about account information databases, smbpasswd looks like it is being phased out and may be deprecated in the future. tdbsam is all the rage now. Basically, the tdbsam password backend stores the old smbpasswd information plus the extended MS Windows NT/200x SAM information into a binary format TDB (trivial database) file. The inclusion of the extended information makes it possible for Samba-3 to implement the same account and system access controls that are possible with MS Windows NT4/200x-based systems. Well, ok. So that's now enabled.

I've also enabled "wins support" so that the nmbd component of Samba can enable its WINS server, telling it to at least try to become a local domain master for my workgroup, which allows Samba to collate browse lists between subnets. This is good, but with the "os level" set to 33, it also allows for some of the other WINS servers in the two subnets to retain their privileges as domain masters themselves after fighting it out. See the gory documentation for details.

Currently, I do not have any additional shares setup besides the [homes] and [printers] groups since the "valid users" option seems to have stopped working as of samba-3.0.23. Until I see evidence to the contrary, or a better HOWTO explaining how things have, or have not, changed in samba-3.0.23a, [homes] is all I have to work with. But, that's ok, since all I ever do from Windows is log into my home directory anyway to access my file system. And with "security = user" set, I will still be prompted for a valid username and password.

Save and exit. Let's check to make sure that the file does not have any syntactical errors:

~> testparm /etc/samba/smb.conf.master
testparm will parse your configuration file and report any unknown parameters or incorrect syntax. It also performs a check for common misconfigurations and will issue a warning if one is found. Always run testparm again whenever you make a configuration change! You will know that you have set up the system properly if you see a message similar to:
Load smb config files from /etc/samba/smb.conf.master
Processing section "[homes]"
Processing section "[printers]"
Loaded services file OK.
Press enter to see a dump of your service definitions
Hit Enter to see the dump of your service definitions. Assuming this is working, let's now use testparm to create a new smb.conf file. For this one time only, login as root instead of using sudo since we are going to be redirecting the output of testparm to smb.conf:
~> su -
# cd /etc/samba
# testparm -s smb.conf.master > smb.conf
Load smb config files from smb.conf.master
Processing section "[homes]"
Processing section "[printers]"
Loaded services file OK.
# exit
Check to verify that smb.conf is present and looks ok using more or less.  

Create a samba Username and Password

Next, we need to create a username and password using that new fandangled tdbsam password database backend. Life is easiest if you choose a username that is equivalent to your Linux username since we won't have to setup a /etc/samba/smbusers file (and possibly winbind).
~> sudo pdbedit -a [user]
Hit Enter, and after typing in your password for sudo (or maybe not) you will be prompted for a "new password". This is the password to be used when logging in from Windows to the Linux filesystem. I like for it to be different than my Linux username password, as a measure of added security. You'll have to retype it a second time to verify, and once done, you will have just added yourself as a new Samba user to the system. If you wish to check the database that was created just created, type:
~> sudo pdbedit -Lv [user]
Deleting an old user can be accomplished by:
~> sudo pdbedit -x [user]
See Chapter 11 regarding account information databases of the Samba documentation for additional information.

Restart samba

With that done, restart the Samba daemons:
~> sudo service nmb restart
You should see both the nmbd daemon successfully restart:
Shutting down NMB services:                                [  OK  ]
Starting NMB services:                                     [  OK  ]
Restart the second daemon:
~> sudo service smb restart
You should see both the smbd daemon successfully restart:
Shutting down SMB services:                                [  OK  ]
Starting SMB services:                                     [  OK  ]
The message may be a bit misleading, however, especially if there is a syntactical error in smb.conf.  If there is an error, smbd will actually fail after creating a pid file. To check that the daemons have indeed started correctly,
~> sudo service nmb status
~> sudo service smb status
You should see verification that both smbd and nmbd are running. If not, go back and comb through the smb.conf.master file for errors, re-create the smb.conf file, and restart the daemons once again. With that, Samba should now be setup properly, assuming that the firewall rules have been applied correctly and SELinux is configured to allow you to connect to your home directory.

Server-side Verification

Now comes the big moment of truth. Well, not quite. Let's use smbclient to check and make sure that we will be able to connect properly from Windows...at least, theoretically:
~> smbclient -L [server]
The [server] variable is the name of your Samba server. When prompted for the password, just hit Enter to login anonymously, or add the "-N" option to force it to list the shares automatically. Assuming things like DNS, /etc/hosts, etc. are setup properly, you'll get a summary of Samba's configuration, including share names, types of shares, servers, workgroups, workgroup masters, comments, etc. The most important thing to verify is that you see a list of the shares that you configured in smb.conf present here. If you do not, then something is configured incorrectly. This method can also be used to see what shares are available on another SMB server, such as Windows 2000.

Next, check to make sure that you can theoretically login correctly:

~> smbclient //[server]/[user]
When prompted for a password, type in the password that you created using pdbedit  your samba password! You should successfully be able to login, and be given a samba prompt:
smb: \>
If you want, you can do things like list the directory (ls), change directories (cd), etc. to test things out. When satisfied, type "quit". If and when this process is finally successful, you'll have a pretty good indication that logging in through Windows may actually work. Often times, the greatest pain in setting up Samba comes from trying to get myself to this point.

Logging in through Windows

Now for the real test. Login to your Windows XP account from another computer, and if you haven't done so already, setup the computer so that it shares the same workgroup name as what you chose for the Samba server. This can be done by clicking on Start -> Control Panel and double clicking on the System icon. Next, click on Computer Name -> Change... and type in the name of your computer and click on the Workgroup button. Then type in the name of the workgroup, which should be the same name used in the smb.conf file. Finally, hit OK. You may have to reboot the computer.

You will also want to poke holes in your Windows firewall. Bring up the Control Panel again, and double click on the Windows Firewall Icon. Then click on Exceptions, and click the File and Printer Sharing option under Programs and Services. Then click, Edit... and allow for TCP Port 139 and UDP Ports 137 and 138 to be opened. Click on OK to close the Edit... window, and OK once again to finish configuring the Windows firewall. You'll notice, once again, that I am keeping TCP Port 445 closed. This is not necessary because I am not using winbind, and also because I am using the Default NetBIOS settings. To check yours, bring up Network Connections, right click on a connection and select Properties from your ethernet connection, and then click on Internet Protocol (TCP/IP) -> Properties -> Advanced... -> WINS. If you want, you input the WINS IP address of the Linux server by clicking on Add..., and when you are finished, by making sure that the Default option is set. Hit OK -> OK -> Close to finish making changes to the connection properties. If you are using a wireless connection as well, you'll want to repeat the process for that connection too.

With that done, you should be able to double click on My Computer -> My Network Places -> View workgroup computers, and an icon with the name "Samba Server" should now be showing, along with the hostname of the actual Samba server (your Linux server). At this point, I like to create a Desktop Shortcut, so that in the future it is easy for me to access the file system. For now, double click on the Samba Server icon, and you should be prompted for your Samba username and password. Upon entering the information, you should now have access to your home directory, along with any network printers that you have setup. If you click on the name of the folder containing your username, you should notice that you are in the actual home directory from your Linux filesystem! You can access, read, write, copy, delete, etc. files back and forth to and from Windows. Use Samba to your heart's content. =p