Gary Dunn, Honolulu first release: 16 Mar 2005 last updated: 3 Feb 2006
Previously this document described FreeBSD 4.x and Gnome 2.10. The only significant change for FreeBSD 5.x is the relocation of some of the mount helper programs from /sbin to /usr/sbin. The instructions below incorporate this change. New to Gnome 2.12 is a useful alternative, described at the end.
WARNING: Implementing these instructions will impact system security. Details follow.
This information applies to Gnome Disk Mounter version 2.12.2 running on FreeBSD 5.4.
As of this writing I have only tested against SMB shares created by Samba on a FreeBSD server, because I do not have access to Windows servers that I can experiment with. Other people report that with Microsoft Windows 2003 Server it is necesary to change a policy that by default requires all connections be encrypted. The policy is called Digitally sign communications and needs to be changed from Always to Disabled. As I understand it, disabling this policy means that encryption will be used when it is available.
Gnome ships with a panel applet called Disk Mounter. I wanted to create a panel along the left edge of my screen with an icon for each of my SMB network shares, so that I could click on an icon and the share would mount.
Windows 2000/XP provides this functionality in the "My Network Places" window. When an icon is double-clicked, the current logon credentials are submitted to the specified server. If this is not enough to grant access, a logon dialog box is displayed.
On UNIX, SMB shares are usually accessed with Samba. The smbclient command can be invoked from the command line with a password specified, or if no password is given, smbclient will prompt for one.
Another option for accessing SMB shares is to mount them, using the mount command with the mount_smbfs helper application.
I wanted to combine Gnome Disk Mounter, mount, and mount_smbfs to make accessing Windows network shares as easy as it is in Windows.
As shipped, the mount and umount commands, as well as the associated mounting programs that mount relies on, can only be successfully run as root. The permissions give everyone execute permission, but something in the way the mount process interacts with the kernel requires that these programs (well, to be more accurate, the few I have used) be run as root.
A little research turned up the fact that in the past, the mount family of programs were typically configured to be setuid. (With this mode set, a program appears to have been run by the owner of the program rather than the person invoking the command. Since mount is owned by root, making it setuid means that even when run by a plain account it will appear to be run by the root account.)
In order for the solution presented here to work, mount_smbfs and umount must be configured setuid. The mount command can be left alone.
This does not automatically open a security hole in your system. It does mean that anyone who can logon can mount a Windows share, but only on a directory they own. By "they own" I do not refer to root, but to the account running the command.
Besides rampant mounting of Windows shares, another security concern is the possibility of an attack based on one of these programs. Some miscreant may discover that when umount is passed a certain bizarre looking command line it can be tricked into running any command on the system. Since it runs as root, the exploit runs as root. This is bad. However, there are no exploits currently described for these programs.
To make the necessary programs setuid, execute this command as root:
chmod 4555 /sbin/umount /usr/sbin/mount_smbfs
The result displayed by
ls -l /sbin/mount /sbin/umount /usr/sbin/mount_smbfs
will look like this:
-r-xr-xr-x 1 root wheel 15016 Jan 9 13:05 /sbin/mount
-r-sr-xr-x 1 root wheel 14332 Jan 9 13:05 /sbin/umount
-r-sr-xr-x 1 root wheel 8912 Jan 9 13:06 /usr/sbin/mount_smbfs
Notice that the line for mount begins -r-x while the other two begin -r-s. That "s" is the setuid flag. Mount does not need to be setuid, but mount_smbfs, the program that does most of the work, does.
To have an icon appear in the Disk Mounter applet there needs to be a corresponding entry in /etc/fstab, and you must own the mount point. Entries in /etc/fstab which do not cut the mustard will not produce an icon. Disk Mounter continuously monitors /etc/fstab, so changes can cause mount icons to flash in and out of existence.
Let's suppose that user bob has access to an SMB share named clowns on a server named bigtop, and that Bob's password is cLoWn90-=
If Samba has been installed on Bob's FreeBSD workstation he should be able to connect with this command:
smbclient //bigtop/clowns cLoWn90-= -U bobIf all goes well you should see some status info followed by a command line:
smb: \>
The quit command will close the connection. It is a good idea to use smbclient in this way to verify the settings before proceeding. However, it is not absolutely necessary.
To get around having the password displayed on the terminal screen, the command could be given this way:
smbclient //bigtop/clowns -U bob
In this case, smbclient will prompt for the password, and it will not be echoed.
Now that we have a working data set, create a mount point and edit /etc/fstab. I recommend placing the mount point under the user's home directory, to make it easier to get to in the file manager and because of the ownership requirement.
First, as the user, not root, create a directory to hold all of the SMB mounts:
cd
mkdir smb
chmod 700 smb
The access mode of 700 is intended to keep stray dogs and cats out, but if it proves to be a problem, experiment.
Now create the mount point for the clowns share. (In case you didn't already know, a mount point is just a directory.)
cd smb
mkdir clowns
chmod 777 clowns
Now you need the real path to your mount point:
cd clowns
pwd
Take the output of the pwd command as the mount point path you will need to put in /etc/fstab. On my system that comes out to
/home/myusername/smb/clowns
but your system is more than likely different.
There are other possibilities. You might prefer to put the mount points alongside cdrom, in the root directory, or in /mnt. The things to watch are ownership and access permissions.
Now that you have a mount point, add it to /etc/fstab with a line like this. You must edit this file as root. Add your line to the end of the file, not at the top:
//bob@bigtop/clowns /home/myusername/smb/clowns smbfs rw,noauto
You can use spaces instead of tabs. smbfs tells mount to use the mount_smbfs mounter, the rw should be ro if the share is actually read-only, and noauto tells your system not to mount this file system automatically when going multi-user. The last two columns in /etc/fstab are numbers, but since in this case they should be zeros they can be omitted. There is no space after the comma after rw.
Save you changes, and test your configuration thus far. As yourself, execute the following from a terminal command line:
mount /home/myusername/smb/clowns
Be sure to use your path and not mine. You should be prompted for a password (the one for the remote server). Enter it, and the share should mount. Open you Home folder, double-click on smb, then clowns, and you should see the contents of your SMB share. Close the file manager windows and, back at the command line, enter this command:
umount /home/myusername/smb/clowns
No output and a command line prompt mean success. If you do get an error, either you misspelled the path or umount's permissions were not set correctly (see above).
At this point you might think that you are ready to add the Disk Mounter applet to a panel, but you would be wrong. We are close, but still have to do something about the password. Disk Mounter will not prompt for a password.
It turns out that mount_smbfs has just what we need. If you read the man page (man mount_smbfs) you will see this, near the bottom:
FILES/etc/fstab
~/.nsmbrc Keeps static parameters for connections and other information.
See /usr/share/examples/smbfs/dot.nsmbrc for details.
That tilde (~) is a place-holder for your home directory, so in my case this file would be
/home/myusername/.nsmbrc
The leading dot is the UNIX way of hiding files from normal listings, and the rc tells us that this is a resource file (literally "run commands").
When I had this working with Gnome 2.8 I could use this file, but with 2.10 it broke. But there is more. In the heavily commented example file it says that there can also be a system-wide rc file that takes precedence to the one in an individual's home directory. This file is
/etc/nsmb.conf
It turns out that Disk Mounter does work with that file. To create it, be root and use your favorite text editor. Enter the following lines:
[default] workgroup=YOURWORKGROUP # describe NT servers [BIGTOP] addr=10.0.1.11 # info for user bob on server bigtop [BIGTOP:BOB] password=cLoWn90-=
Obviously, a lot of what you enter will be different than what you see here. Be sure to insert the real IP address of the server. If you prefer, you can use the registered Internet Domain name in place of the IP address. In this example, Bob is using a strong password that begins with a lowercase "c" and ends with an equal sign.
After you save this file, ensure that it is owned by root and can be accessed only by root:
chmod 600 /etc/nsmb.conf
chown root:wheel /etc/nsmb.conf
If you have not yet added the Disk Mounter applet to a panel, do so now by right clicking the panel and selecting "Add to panel" on the pop-up menu. You should see an icon for your share. Click it and a short pop-up menu will appear, with an option to mount your disk. It should work.
To connect to a Windows share the connection process must provide a username and password. Disk Mounter will not prompt for a password. This problem is solved with the /etc/nsmb.conf file. However, passwords are stored in this file in clear text ... unencrypted. This means that everyone with root access to the computer can see and steal all of the passwords stored in /etc/nsmb.conf. On a personal workstation, with one user who is also the system administrator, this is not a problem. When a computer is shared, the administrator must be exceptionally trustworthy.
Unfortunately there are a lot of details involved, which means a lot to go wrong. To summarize:
If you do not see an icon for your share, there is a problem with the data in /etc/fstab, or ownership or access permissions of the mount point.
If you get an icon but cannot connect, double-check the server and user info in /etc/nsmb.conf.
If you have installed Samba you can use smbclient to troubleshoot.
Starting with Gnome 2.12 you have an alternative to the process described above. In the end, the difference is that with the above method -- we'll call that smbfs -- the /etc/nsmb.conf supplies the passwords, whereas with Gnome's built-in SMB support you must enter passwords yourself. Another difference is that the built-in method does not work with the Disk Mounter applet.
To set up a connection, click on the Gnome Places menu and select Connect to Server. Change the Service type to Windows share. This will alter the initial dialog box. Continue filling in, typically the Server, Share, User Name, and Name to use for connection. The last one is like an alias; it is what the link on your desktop will be named.
If the server and share are found aa Authentication Required dialog will be displayed. This is where you enter the password required by the Windows server, the one that matches the User Name provided in the previous step. There are two options that you can check, Remember password for this session and Save password in keyring. "Session" refers to being logged in on the local workstation, so if you are in the habit of staying logged in for days at a ime this may not be good for you. The keychain stores sets of username password pairs, all accessible via a single password. Every time you connect to a share you will be asked for the keychain password.
When you have establised a connection a network folder icon will appear on your desktop, and in the Places/Computer window. Double-click the icon to navigate through the share. If you log off and back on, the icon is still there, but the connection is gone. When you double-click the icon you will be prompted for a password, the one for the User Name you defined or, if you chose to use the keyring, the password to unlock the keyring.
To delete a connection entirely, right-click the folder icon and select Unmount Volume.
I think the choice of which method to use depends on how many people have root access to the workstatio. If you are the only one, the smbfs method is more convenient. If other people have root access, go with the Gnome built-in method, because passwords are not stored as clear text.
Please send comments and corrections to Gary Dunn, knowtree@aloha.com