Welcome to Eric Hameleers (Alien BOB)'s Wiki pages.

If you want to support my work, please consider a small donation:

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

slackware:samba [2006/03/21 22:34]
alien
slackware:samba [2006/03/29 19:27] (current)
alien
Line 10: Line 10:
 This will not be a complete hand-holding experience - I will assume you've got at least a basic knowledge of Linux, Samba and (possibly) NFS. This article helps you get things right, when you tried and failed before. This will not be a complete hand-holding experience - I will assume you've got at least a basic knowledge of Linux, Samba and (possibly) NFS. This article helps you get things right, when you tried and failed before.
  
-Having said that, let's delve a little deeper. There are two basic methods of accessing files on filesystems located on a networked machine. When you're a Windows users, filesharing amounts to //Windows File Sharing// using the SMB or CIFS protocols. These protocols are built into Windows, so why let them go to waste? I'll describe how you setup a Samba server on your central Linux box and all your Windows clients will be happy. Looking at Linux users, the horizon broadens. Here, we face several more alternatives, Samba and NFS being the two that will be available to virtually every Linux user. NFS has the advantage of being able to map all the user IDs on the server to the same user IDs of the client. With Samba, an exported share can be mounted on the client (provided you have sufficient access rights) using another user ID or group ID than that of the original files.+Having said that, let's delve a little deeper. There are two basic methods of accessing files on filesystems located on a networked machine. When you're a Windows users, filesharing amounts to //Windows File Sharing// using the SMB or CIFS protocols. These protocols are built into Windows, so why let them go to waste? I'll describe how you setup a Samba server on your central Linux box and all your Windows clients will be happy. Looking at Linux users, the horizon broadens. Here, we face several more alternatives, Samba and NFS being the two that will be available to virtually every Linux user. NFS has the advantage of being able to map all the user IDs on the server to the same user IDs of the client. With Samba, an exported share can be [[#the_linux_client_setup |mounted on the client]] (provided you have sufficient access rights) using another user ID or group ID than that of the original files.
  
 The rest of the article will describe how to set up a Samba server as well as a NFS server, and enhance the network experience of your fellow computer users (or perhaps it's only you that will be using Samba). Setting up networked printers will also be discussed. An [[slackware:cups | article on setting up CUPS]] printing is not in scope of this article, but we do need a configured CUPS server if we want to print from our Windows clients. The rest of the article will describe how to set up a Samba server as well as a NFS server, and enhance the network experience of your fellow computer users (or perhaps it's only you that will be using Samba). Setting up networked printers will also be discussed. An [[slackware:cups | article on setting up CUPS]] printing is not in scope of this article, but we do need a configured CUPS server if we want to print from our Windows clients.
Line 18: Line 18:
 ----------------------------------------- -----------------------------------------
  
-The exercise is meant to setup a Samba server where you make available several shares, some username/password protected, others that don't need a password. People will be able to connect to their homedirectory on the server. The printers that were configured in the CUPS printserver will be available as shared network printers through Samba, and Windows printer driver files can be automatically downloaded from the Samba server by Windows clients. So far, sounds nice, doesn't it? The next paragraph contains an example [[#a_sample_smb.conf | smb.conf file]] that is based on what we're about to do.\\+The exercise is meant to setup a Samba server where you make available several shares, some username/password protected, others that don't need a password. People will be able to connect to their homedirectory on the server. The printers that were configured in the CUPS printserver will be available as shared network printers through Samba, and Windows printer driver files can be automatically downloaded from the Samba server by Windows clients. So far, sounds nice, doesn't it? The last section of this paragraph contains an example [[#a_sample_smb.conf | smb.conf file]] that is based on what I'about to tell.\\
 Here is the skinny: Here is the skinny:
  
Line 59: Line 59:
   * Make sure you have configured printers in CUPS if you want to use printing in Samba. For Linux, you will use a CUPS printer configuration that is using the printer-specific PPD file, but for Windows clients, you will have to setup additional printer queues that use //RAW// printing (i.e. CUPS does not mess with the incoming printer data and passes the data on to the printer unaltered). The CUPS server does not know about raw printer data by default, so you will have to uncomment a couple of lines.\\   * Make sure you have configured printers in CUPS if you want to use printing in Samba. For Linux, you will use a CUPS printer configuration that is using the printer-specific PPD file, but for Windows clients, you will have to setup additional printer queues that use //RAW// printing (i.e. CUPS does not mess with the incoming printer data and passes the data on to the printer unaltered). The CUPS server does not know about raw printer data by default, so you will have to uncomment a couple of lines.\\
   - In the file ''/etc/cups/mime.types'' uncomment the line ''application/octet-stream''   - In the file ''/etc/cups/mime.types'' uncomment the line ''application/octet-stream''
-  - In the file ''/etc/cups/mime.convs'' uncomment ''application/octet-stream  application/vnd.cups-raw 0 - '' +  - In the file ''/etc/cups/mime.convs'' uncomment ''application/octet-stream  application/vnd.cups-raw 0 - '' And then restart CUPS daemon using <code>/etc/rc.d/rc.cups restart</code>
-And then restart CUPS daemon using <code>/etc/rc.d/rc.cups restart</code>+
  
-  * It is now time to fire up our Samba server. But we will test the configuration first by running the command ''testparm''. IT will show us if anything went wrong while editing the ''smb.conf'' file. If everything seems allright, we will procede with making the  Samba start script executable (so that it will still start when we boot our server) and then running the script: <code>+  * It is now time to fire up our Samba server. But we will test the configuration first by running the command ''testparm''. It will show us if anything went wrong while editing the ''smb.conf'' file. If everything seems allright, we will procede with making the  Samba start script executable (so that it will still start when we boot our server) and then running the script: <code>
 chmod +x /etc/rc.d/rc.samba chmod +x /etc/rc.d/rc.samba
 /etc/rc.d/rc.samba start /etc/rc.d/rc.samba start
-</code> Check if your server is up and running: <code>+</code> Check if your server is up and running by using either of these two commands: <code>
 smbclient -L localhost smbclient -L localhost
-</code> The result should be a dump of the visible shares that are defined in Samba, plus a list of computers in the network that also talk the //Windows File Sharing// protocol (this list will be small or empty at first, it may take up to 15 minutes for machines in the network to become aware of each other).+</code> The result should be a dump of the visible shares that are defined in Samba, plus a list of computers in the network that also talk the //Windows File Sharing// protocol (this list will be small or empty at first, it may take up to 15 minutes for machines in the network to become aware of each other). <code> 
 +smbstatus 
 +</code> which will give an overview of the activity on the Samba server (a verbose list of connected shares and open files).
  
 Was it really that easy? Yes! It really is that easy. We have of course not yet messed with networkprinters, or password-protected shares, but the basics are there. You can take a Windows machine and (if you followed my example to the letter) try to connect to ''\\BOB\PUBLIC'' and see your Linux ftp server directories. Was it really that easy? Yes! It really is that easy. We have of course not yet messed with networkprinters, or password-protected shares, but the basics are there. You can take a Windows machine and (if you followed my example to the letter) try to connect to ''\\BOB\PUBLIC'' and see your Linux ftp server directories.
Line 76: Line 77:
 There are some topics I have to cover. These are: password-protected access, and Windows clients. There are some topics I have to cover. These are: password-protected access, and Windows clients.
  
 +== Windows clients ==
 +
 +Ever since Windows 98 and NT4SP3, windows clients exchange encrypted passwords with the server. The Samba server is configured for encrypted passwords, so this will cause no problems. Only DOS, and Windows 95 clients will //not// be able to access our Samba server. People with these old Operating Systems in their network will need to disable the use of encrypted passwords on their other OS'es like Windows 2000/XP and Samba. The line to add to your ''/etc/samba/smb.conf'' is <code>
 +  encrypt passwords = no
 +</code>
 +With Windows XP, the authentication mechanism changed somewhat, due to MS Active Directory (AD) support. A Windows XP client can only connect and authenticate against a Samba server after a small registry modification (the //requiresignorseal// hack). This is the registry key - save this in a file with extension ''.reg'' and double-click on it. XP will ask if you want to merge the files's key into the Windows registry. You want that. <code>
 +Windows Registry Editor Version 5.00
 +
 +;
 +; This registry key is needed for a Windows XP Client to join
 +; and logon to a Samba domain. Note: Samba 2.2.3a contained
 +; this key in a broken format which did nothing to the registry -
 +; however XP reported "registry key imported". If in doubt
 +; check the key by hand with regedit.
 +
 +[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
 +"requiresignorseal"=dword:00000000
 +</code> You can find this file (''/usr/doc/samba-3.0.xx/docs/registry/WinXP_SignOrSeal.reg'') and several others in the Samba documentation directory on your Linux box.
 +
 +== Passwords in Samba ==
 +
 +The Samba server will use your local Linux accounts (the ones in ''/etc/passwd'') but with encrypted passwords enabled (see above) Samba must have a way of storing these passwords somewhere. They are incompatible with the Linux account passwords that you find in ''/etc/shadow''. Samba keeps a database with these encrypted passwords and the trick is to keep these synchronized with the Linux passwords. The lines in ''smb.conf'' <code>
 +# Synchronize Samba and Unix passwords
 +   passwd program = /usr/bin/passwd %u
 +   passwd chat = *password* %n\n *password* %n\n *changed*
 +   unix password sync = Yes
 +</code> will take care of that.\\
 +There is one caveat: for every Linux account that wants to use the Samba server, you will have to add the entry in the Samba password database manually. You do this as root, and it's only needed once for every user: <code>
 +smbpasswd -a <some_username>
 +</code> The ''smbpasswd'' command can be used later on to change the Samba password //and// the Linux password together by running <code>
 +smbpasswd <some_username>
 +</code> A Windows user can use the ''<CTRL><ALT><DEL>'' sequence to change the password!
 +
 +
 +=== Samba printers ===
 +
 +If you have a configured and running CUPS server that has at least one queue setup for //RAW// printing, we can now proceed with integrating this CUPS printer queue with our Samba server, so that Windows clients can automatically download their printer drivers from the Samba server. This is of course more convenient than accessing each and every Windows PC with a printer driver CD and manually configuring the printer.
 +
 +Using the directions of the previous sections and the [[#a_sample_smb.conf|smb.conf example]] of the last section, you have everything in place already, server-side. You will now have to take a Windows XP workstation, and logon to a Samba share using an account that is known to Samba as a //printer admin//. In our setup, that means: everyone who is a member of the Linux group [[linux:admin#wheel]].
 +
 +FIXME //to be completed// FIXME
  
 === The Linux client setup === === The Linux client setup ===
  
 On a linux client computer, it is the ''smbmount'' command that lets you mount a Samba (or a Windows!) share on the local filesystem. You can run the command manually in a console like this: <code> On a linux client computer, it is the ''smbmount'' command that lets you mount a Samba (or a Windows!) share on the local filesystem. You can run the command manually in a console like this: <code>
-mount -t smbfs //192.168.0.1/mp3 /mnt/samba/bob/mp3 -o rw,uid=0,gid=10,fmask=664,dmask=775 -U <some_special_user> +mount -t smbfs //192.168.0.1/public /mnt/samba/bob/public -o rw,uid=0,gid=10,fmask=664,dmask=775 -U <some_special_user> 
-</code> which will mount the share called //mp3// on our server called //bob// which has the IP Address ''192.168.0.1'' in this example. The mountpoint ''/mnt/samba/bob/mp3'' must of course be created as a directory before. I chose ''/mnt/samba/bob/mp3'' arbitrarily, I like looking at the mount point's name and be able to guess what it is all about. You are of course free to take another mount point.\\ The command mounts the share as user //<some_special_user>// and it's up to you who that user account is, as long as it has the necessary access rights to the share. If the account has a password associated with it, you will be asked for it.\\+</code> which will mount the share called //public// on our server called //bob// which has the IP Address ''192.168.0.1'' in this example. The mountpoint ''/mnt/samba/bob/public'' must of course be created as a directory before. I chose ''/mnt/samba/bob/public'' arbitrarily, I like looking at the mount point's name and be able to guess what it is all about. You are of course free to take another mount point.\\ The command mounts the share as user //<some_special_user>// and it's up to you who that user account is, as long as it has the necessary access rights to the share. If the account has a password associated with it, you will be asked for it.\\
 The //-o rw,uid=0,gid=10,fmask=664,dmask=775// part means that the remote share will be mounted locally read/write, seemingly owned by user root:wheel (uid=0, gid=10) and with file- and directory masks that make the share's files and directories read/only for non-root, non-[[linux:security#wheel | wheel users]]. Having to type all this in order to mount the share is a tedious effort, so we take the easy way and add the following line to ''/etc/fstab'': <code> The //-o rw,uid=0,gid=10,fmask=664,dmask=775// part means that the remote share will be mounted locally read/write, seemingly owned by user root:wheel (uid=0, gid=10) and with file- and directory masks that make the share's files and directories read/only for non-root, non-[[linux:security#wheel | wheel users]]. Having to type all this in order to mount the share is a tedious effort, so we take the easy way and add the following line to ''/etc/fstab'': <code>
-//192.168.0.1/mp3 /mnt/samba/bob/mp3  smbfs rw,uid=0,gid=10,fmask=664,dmask=775,credentials=/etc/bob.cred  0 0 +//192.168.0.1/public /mnt/samba/bob/public  smbfs rw,uid=0,gid=10,fmask=664,dmask=775,credentials=/etc/bob.cred  0 0 
-</code> We store the username and password that we need to gain access to the //mp3// share, in a file called ''/etc/bob.cred'' which we protect from curious eyes by removing read access for all but the root user: <code>+</code> We store the username and password that we need for gaining access to the //public// share, in a file called ''/etc/bob.cred'' which we protect from prying eyes by removing read access for all but the root user: <code>
 chmod 600 /etc/bob.cred chmod 600 /etc/bob.cred
 </code> The contents of that file are like this: <code> </code> The contents of that file are like this: <code>
 username = <some_special_user> username = <some_special_user>
 password = <the_secret_word> password = <the_secret_word>
-</code>+</code> Having this in our client computer's ''/etc/fstab'' will cause the samba share to be automatically mounted when the computer boots. 
 + 
 +=== Mixing protected and passwordless shares === 
 + 
 +<note tip>A note on the sometimes unexpected consequences of using a mix of passwordless shares (like the //PUBLIC// share in my example) and protected shares, where you have to type a username and password to access the data (like the //HOMES// share in the example). 
 +</note> 
 +Windows will not allow you to logon to a Samba (or even a real Windows) server using more than one set of credentials. This means that if you start with a connection to a passwordless share, you actually are using the "guest" credentials. Once you've done that, there is no way you can map your homedirectory for instance - Samba will of course ask you for a valid account/password combination, and you can actually enter those in the Windows dialog box that will appear, but after clicking on //OK//, Windows will complain that it can only use a single set of credentials and will refuse to map to your protected Samba share.\\ 
 +This is annoying, and on some occasions it will be sufficient to close the Windows Explorer, open another, and then remove the lingering "guest" network connection through the "Extra" menu of the Windows Explorer. After doing so, Windows will accept your credentials and map you to your Samba home directory.\\ 
 +Things can become more difficult once you've connected to a //printer share// that is exported by the Samba server. If printing does not require a password (because that is quite convenient) and you have printed anything, it will be //very// hard to get rid of the "guest" connection to the Samba server because the Windows printing subsystem will keep opening that connection. In many such cases, you will have to reboot the Windows PC in order to map to a protected share. __Or__, use the IP address or internet host name of the Samba server for your password-protected share access (like, try to connect to //''\\192.168.0.1\alien''// instead of the usual //''\\bob\alien''//). This will force the protocol to the more modern CIFS instead of SMB, and then you won't have this problem. 
 + 
 === A sample smb.conf === === A sample smb.conf ===
  
Line 345: Line 397:
 #   wide links = yes #   wide links = yes
 </code> </code>
 +
 +==== Setting up NFS on Slackware ====
 +-------------------------------------
 +
 +Actually, setting up a NFS for Slackware is even easier than Samba.
 +
 +
 +=== NFS Server ===
 +
 +You setup an NFS server by creating or editing the file ''/etc/exports''. That file has a man page (man exports) and I encourage you to read that if you want more than my simple example. But basically, this file can look like this: <code>
 +# See exports(5) for a description.
 +# This file contains a list of all directories exported to other computers.
 +# It is used by rpc.nfsd and rpc.mountd.
 +/home                192.168.0.0/24(rw,async,no_root_squash)
 +/var/www/htdocs      192.168.0.0/24(rw,all_squash,anonuid=99,anongid=99)
 +/home/ftp/pub        192.168.0.0/24(ro,sync,insecure,all_squash)
 +</code> This creates three exports, all accessible by any client with an IP address in the range ''192.168.0.0/24''. I'll discuss them in reverse order:
 +  - the ftp server's 'pub' directory aka the anonymous ftp area. This export will be available as read-only (the 'ro' parameter) with as safe as possible settings
 +  - your webserver's DocumentRoot (/var/www/htdocs) which will be available as writable, but on the server side, all writes will appear to originate from the user with the userid:groupid of ''99:99'' which is actually the "nobody" user. If you let the DocumentRoot tree be owned by this account (a configuration you often see), then the Web Server's CGI or PHP scripts can write files in these directories
 +  - the server's ''/home'' directory tree which can be mounted writable (the 'rw') using asynchronous transfers (faster but with a chance of data corruption in case of a server crash - 'sync' is safe but slower). User ID's (//uid//) and group ID's (//gid//) will be mapped 1-on-1 (even for user 'root' - the 'no_root_squash' option). This means, if the server knows a user 'alien' with a "uid:gid" pair of ''1001:100'', then alien's files in his homedirectory will appear with this uid:gid number pair on the NFS client side as well! So, if the NFS client PC also has an account 'alien' with the same "uid:gid" number pair ''1001:100'', this alien will be able to use the files on the server as they were his own.
 +<note important>You see why it is important to create users on your LAN with the same UID (and GID) on //all// computers if you ever intend to install a NFS server.</note>
 +
 +=== NFS client ===
 +
 +On a NFS client, you should enable the //portmapper//. To do so, activate the rc script and then run that script -once- manually (saves you a reboot to make it work) <code>
 +chmod +x /etc/rc.d/rc.portmap
 +/etc/rc.d/rc.portmap start
 +</code> Should you ever forget this, you will still be able to mount a NFS export, but it will take __//forever//__ for the mount command to return to the prompt (if you run the mount command in a console).
 +
 +Next, you should add a line to your ''/etc/fstab'' for the NFS export that you want to mount on your NFS client. Suppose your NFS server has IP Address ''192.168.0.1'' and it exports ''/home'' you could add this line to the fstab file: <code>
 +192.168.0.1:/home  /mnt/nfs/home  nfs  auto,rsize=8192,wsize=8192,hard,intr  0   0
 +</code> This NFS export will then automatically be mounted by Slackware when booting up. The manual mount command  would be: <code>
 +mount -t nfs -o rsize=8192,wsize=8192,hard,intr 192.168.0.1:/home  /mnt/nfs/home
 +</code> Note, that I expect you to create the mount point (''/mnt/nfs/home'' in the example, but you may pick your own of course) in advance...!
 +
 +I hear you thinking... how do I find out the export list of my NFS server? This is easy: run <code>showmount -e <NFS_servername></code> to obtain a list. This is what the output will look like: <code>
 +# showmount -e bob
 +Export list for bob:
 +/home                          192.168.0.0/24
 +/var/www/htdocs                192.168.0.0/24
 +/home/ftp/pub                  192.168.0.0/24
 +</code> Note that this specific NFS server also exports the webserver's DocumentRoot and the ftp server's 'pub' directory. What you //don't// see how those exports are configured (access restrictions and such, apart from the allowed IP address range). 
 +

Personal Tools
sponsoring