"Samba is a suite of Unix applications that speak the SMB (Server Message Block) protocol. Many operating systems, including Windows and OS/2, use SMB to perform client-server networking. By supporting this protocol, Samba allows Unix servers [including Linux] to get in on the action, communicating with the same networking protocol as Microsoft Windows products. Thus, a Samba-enabled Unix machine can masquerade as a server on your Microsoft network and offer the following services:So what does this mean? In short, Samba, running on a Unix box, can act as a file or printserver for computers running Windows 9x/NT.
· Share one or more filesystems
· Share printers installed on both the server and its clients
· Assist clients with Network Neighborhood browsing…"
Why would anyone want to connect Unix and Windows? It’s common to see companies using Unix servers for more intensive, mission critical tasks, while the majority of employees use Windows. Samba allows a systems administrator to tie these two groups together, allowing Windows workstations to access filespace and printers via a Unix server. On the other hand, smaller business, whose employees use Windows and share files (Peer-to-Peer) through the Network Neighborhood may also find Samba prodigious. In this case, they might be interested in creating a system that centrally stores and backs up their files, while offering printer access to an entire office. Since their employees already use Windows 9x/NT as a client, they might first investigate setting up a Microsoft server. However the cost for several client licenses along with Microsoft’s server software can cost thousands of dollars for only a dozen employees. Thus a Microsoft solution is often cost-ineffective and considered less reliable than a Unix server. Why would a small business choose Samba? Well, using a computer no different that an equivalent Windows workstation can be set up running Linux and Samba for virtually nothing, as they both can be obtained freely under various open-source licenses. Thus larger businesses can use Samba to integrate a pre-existing Unix/Windows environment whereas smaller businesses can use introduce Linux and Samba to their Windows environment in order to add additional server functionality without the expensive cost associated with Microsoft's server software.
I happen to work for a department very similar to the second case described above, so as a result I decided to investigate Samba as an alternative to their present filesharing setup, using sharing drive partitions through Microsoft's Network Neighborhood.
rpm –qa | grep samba
I downloaded the latest version of samba (samba-2.0.7) from ftp://ftp.samba.org/pub/samba/.
I decompressed it and I untarred it:
gunzip samba-2.0.7.tar.gz; tar xof samba-2.0.7.tar
At this point I had all of the source in a samba-2.0.7/ directory. Having already read most of the SMB-HOWTO and the O’Reilly "officially adopted" Samba book, Using Samba I proceeded without perusing the README/UNIX_INSTALL.txt files:
./configure
make
make install
The install went very smoothly, depositing the files in /usr/local/samba/. I knew this would not be as simple as an RPM install, which meant I would also have to modify some system files that would ‘turn’ Samba on, either via inetd, or by running as a daemon. The literature implied that Samba ran faster as a daemon, so I opted for that method. The simplest way to achieve this would have been to include these two lines at the bottom of the /etc/rc.d/rc.local file:
/usr/local/samba/bin/smbd -D
/usr/local/samba/bin/nmbd -D
In other words those lines would start the Samba daemons when the system booted. I knew that they would make Samba work, but I wanted a more elegant solution, which I found in the SMB-HOWTO file. That gave an example of a startup script (below) that I could place in the /etc/rc.d/init.d/ directory and then could create links to from the various runlevel directories.
#!/bin/sh
# /etc/rc.d/init.d/smb - starts and stops SMB services.
#
# The following files should be symbolic links to this file:
# symlinks: /etc/rc.d/rc1.d/K35smb (Kills SMB services on
shutdown)
# /etc/rc.d/rc3.d/S91smb (Starts
SMB services in multiuser mode)
# /etc/rc.d/rc6.d/K35smb (Kills SMB
services on reboot)
#
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
# See how we were called.
case "$1" in
start)
echo -n "Starting SMB services: "
daemon smbd -D
daemon nmbd -D
echo
touch /var/lock/subsys/smb
;;
stop)
echo -n "Shutting down SMB services: "
killproc smbd
killproc nmbd
rm -f /var/lock/subsys/smb
echo ""
;;
*)
echo "Usage: smb {start|stop}"
exit 1
esac
I saved the script in /etc/rc.d/init.d, and I made sure it would be executable by issuing the command:
chmod 755 smb
Then I created symbolic links to smb in the appropriate runlevel directories:
ln –s /etc/rc.d/init.d/smb /etc/rc.d/rc3.d/S91smb
(Starts SMB services when Linux boots)
ln –s /etc/rc.d/init.d/smb /etc/rc.d/rc1.d/K35smb
(Kills SMB services when Linux shuts down)
ln –s /etc/rc.d/init.d/smb /etc/rc.d/rc6.d/K35smb
(Kills SMB services when Linux reboots)
Before I could start Samba using the script and links above, I knew I had to edit its configuration file, /usr/local/samba/lib/smb.conf which would designate certain folders on the Linux filesystem to share. The easiest way I found to do this is just by editing the file which I have included below with comments describing each line:
[global]
# Global settings that apply to all following shares
workgroup = INLS183
# Sets the workgroup in which the server appears
netbios name = PURPLE
# Sets the name of the server
server string = Samba %v
# Sets the description/comment about the server
encrypt passwords = Yes
# Tells Samba to expect Windows encrypted passwords
hosts allow = 152.2. localhost # Tells Samba only to allow
connections from 152.2.X.X IP addresses (and localhost)
[guests]
# Name of share = 'guests'
comment = purple's guests
# Comment associated with share
path = /export/samba/guests # Path to
shared folder on the Unix system
guest ok = Yes
# Means guests can read these files
read only = Yes
# Means no one can write to these files
[users]
# Name of share = 'users'
comment = purple users
# Comment associated with share
path = /export/samba/users # Path
to shared folder on the Unix system
writeable = Yes
# Means that files in this folder can be modified
Once I saved the file, I created the directories:
mkdir -P /export/samba/guests /export/samba/users
and I changed their permissions:
chmod 755 /export/samba/guests /export/samba/users
In order to check my syntax in the smb.conf file, I ran another Samba utility, /usr/local/samba/bin/testparm, which verifies smb.conf. As my file was small and simple, it found no errors.
The last change I had to make on the Linux end before starting Samba was to use the Samba password utility (/usr/local/samba/bin/smbpasswd) to create an encrypted password entry for my Linux userID. The reasoning behind this has to do with a change that was made in Windows from NT SP3 and 95 OSR2 to the present. Microsoft decided to send encrypted passwords when trying to authenticate services like Samba. Though arguably this does provide a better level of security, it also means that Samba must be instructed to expect encrypted passwords using the “encrypt passwords = Yes” option in the smb.conf file. This instructs Samba to look in the /usr/local/samba/private/smbpasswd file to authenticate the password sent by Microsoft. As I mentioned above, in order to generate an encrypted password in the smbpasswd file, one must use the smbpasswd utility like this:
[root@purple init.d]# /usr/local/samba/bin/smbpasswd –a jwatt
New SMB password:
Retype new SMB password:
Password changed for user jwatt.
At this point everything is ready to go. So I started the server by issuing the command:
/etc/rc.d/init.d/smb start
and Samba started!
To see if Samba was working, I checked the Network Neighborhood for a workgroup called INLS183, which I had set up in the smb.conf file. I couldn’t find one. Either Samba wasn’t working, or the ILS subnet is separated from the North Campus such that Network Neighborhood traffic does not travel between the two. This was my first problem. If I couldn’t find the computer, how could I get to it? The book suggested that I could access the computers by typing it's name into the Start => Run dialog box, so I typed:
\\Purple
but I didn’t get anything but a generic "The network name cannot be found" error. So, on a hunch I typed:
\\152.2.81.90 (Purple’s IP address)
Initially nothing happened, but then Purple appeared, showing the two shares that I had set up, "guests" and "users". Later I discovered I could find \\Purple [using its NetBIOS name] by putting this line in the C:\Windows\lmhosts file:
152.2.81.90 Purple #PRE
At this point, Samba was working. If my dorm computer and Purple were on the same local-area network, I would have able to see the INLS183 workgroup, and inside it I would have seen Purple. However, because UNC is something of a wide-area network, I am apparently unable to browse the ILS subnet from my North Campus dorm room. Otherwise, the installation and configuration was a success drawing on my knowledge of both the Unix and Windows environments.
However, Samba sets that progress back. Now not only does there need to be a specific userID to access the Samba share, but it has to have a specific password that matches the one in the smbpasswd file. Since I was considering setting up Linux and Samba in an office I administer, it meant that I would have to tediously install TweakUI on every client and then instruct everyone in the office about what to do if TweakUI lapses, which it often does.
I was hoping there would be a way to get around the need to enter a password when Windows boots--that Samba would accept. I decided to investigate how Samba would respond if I didn’t follow the instructions in Using Samba, but rather set my Windows password to "" [null].
To accomplish this, I set Control Panel => Passwords => User Profiles back to the first option, and I deleted my *.pwl file. When Windows rebooted, it sensed that there wasn’t a .pwl file, so it prompted me to enter a userID and a password—which comes with a caveat, saying that if I don’t enter a password, I won’t get this prompt again at startup. (Yippee!) So I set the userID to "jwatt", and I left the password blank. As the tip promised, Windows did not prompt for a password upon reboot.
Thinking at first that the Samba password needed to match the Windows password, I set the Samba passwd to "" [null] as well, and when I tried to access the Samba share I was immediately given access.
Now security-wise, setting my password to blank is kind of scary, especially with the machine live on the Internet. So started to wonder what Windows would do if the Samba password was substantial while the Windows password was "" [null]? Again, I deleted my pwl file, logged off then on again, and I changed my Samba password to something more reasonable. I wasn’t expecting much because all the literature suggested that my underlying Windows password had to match the Samba password for this process to work correctly.
When I tried to access \\152.2.81.90 it prompted for a password just as if I was asking permission to browse a password protected share in the dorm. The prompt said:
“You must supply a password to make this connection:The book had mentioned that if I ever saw IPC$, then something was probably wrong between the Windows and Samba password, and they suggested that it was probably because Samba was expecting a plain text password while Windows was sending its newly encrypted passwords. Rather that admit defeat I typed in that new substantial password I had set for Samba, and I made sure to check the box below that said “Save this password in your password list” I hit enter and it opened the share. I could browse and edit at will. And even better, the next time I opened \\152.2.81.90 I didn’t have to enter a password because I had instructed Windows to save the password—and this holds true even after rebooting the machine.
Resource: \\152.2.81.90\IPC$”
[Granted, there are a number potential security holes here, the most prominent being that the password to the share is stored in the weakly encrypted *.pwl file; also anyone that has physical access to my machine would be able to access the share without any authentication. However, for a small office without many security concerns, the ease of this solution probably outweighs the risk.]
In essence I found the solution I was looking for, and one that I would probably employ in my office: I will assign each machine a userID that matches their Linux/Samba userID, but I will configure Windows, as I mentioned above, not to ask for a password until the share is accessed. Then of course I can preload each machine by typing in the Samba password (which Windows saves more or less indefinitely), and I can do all of this without further complicating the requirements I place on my users.
INLS 183 Project 1: Samba-2.0.7 script file