Introduction: This tutorial shows HowTo mount folders shared on a network fileserver as network drives on a Samba Client machine (on a Samba SOHO LAN). Confusion arose when the cifs filesystem replacesd the smbfs filesystem in openSUSE 10.2, although there was no functional change. Network drives can be configured to be variously accessible, ranging from available to strictly one user through to available to everyone.

Note that mounting a folder shared from a Windows file server is the same from the point of view of the Linux client as mounting a folder shared from a Linux file server. Your being aware that this tutorial essentially covers both cases at once will save me lots of typing.

Mindset: Shares on a server that are destined for mapping/mounting as network drives are constructed with subtle differences from shares that are destined for use in a network browser. I present ways to configure the underlying share with a view to making the resulting mapped drives effective.

The problem subdivides into two main aspects: (1) HowTo mount a share and (2) HowTo make a share

Check packages: In Yast –> Software management –> use the search term “cifs” and check/install cifs-mount & pam-cifs. Check search also on “samba” and install samba, samba-client, kdebase3-samba if using KDE and nautilus-share if using Gnome.

Setting the Scene: Suppose we have a file server with IP address e.g. 192.168.44.100 and with netBIOS name “suseserver”. The folder to be shared is located in the home filesystem of an ordinary user and it’s named “origin” for this exercise. The client workstation, “suseclient”, has a folder named “destination” in the home directory of an ordinary user. The network share will be mounted in this folder. The owners of the folders “origin” and “destination” don’t have to be the same user.

You need a minimum of one member of the Samba user database on the server if you want to map useful network drives. Suppose for this exercise the user is “netuser” with password “hiddenword”. Netuser can be, but doesn’t have to be the owner of the shared folder “origin”. Netuser can even be a dummy without a home folder if you wish. You add netuser to the Samba database on the server in a terminal session like this:

username@suseserver:~> sudo smbpasswd -a netuser
root's password: xxxxxxxxxxxx
New SMB password: hiddenword
Retype new SMB password: hiddenword
Added user netuser.
username@suseserver:~>

With those preliminaries completed, you can map shares across to the client machine as network drives. The network drives can be either temporary (made by command in a terminal) or permanent (mounted at boot via an entry in fstab).

Temporary Mounts: You issue a command in a root terminal on the client machine to mount the share. The session goes like this on the client machine (note that line 3 is all-one-line):

username@suseclient:~> su

Password:

username@suseclient:~> # mount -t cifs -o username=netuser,password=hiddenword //192.168.44.100/origin /home/username/destination

username@suseclient:~> #

Permanent Mounts: If you want the mapped drive to be always present then you don’t use the on-the-fly command line approach detailed above. Instead you mount the drive at boot by adding a line to the text file that contains the file system table. It’s called fstab and it’s located at /etc/fstab. To open file fstab in the text editor “gedit”, a Gnome user issues the following command in a terminal:

username@suseclient:~> gnomesu gedit /etc/fstab

Or if you use KDE you issue this command to open fstab in the the KDE editor “kwrite”:

username@suseclient:~> kdesu kwrite /etc/fstab

And you insert the following entry, all as one line, at the bottom of the fstab file:

//192.168.44.100/origin /home/username/destination cifs 
username=netuser,password=hiddenword,auto,uid=a_user_name,gid=users 0 0

Who is “a_user_name” in this specification? This would normally be the owner of the shared folder on the server (e.g. origin). Then the ownership and permissions attached to “origin” folder will map across nicely to the mount-folder (e.g. destination) on the server.

Some of you will wonder if you can use numerical values like uid=1004 and gid=100 in place of uid=a_user_name and gid=users. You can.

Reboot and the files in the shared folder on “fileserver” will be accessible in folder “destination” on the client.

Here’s a very curious and somewhat annoying openSUSE bug: In openSUSE 10.2 you can use the netBIOS name (e.g. suseserver) instead of the IP address (e.g. 192.168.44.100) in the fstab entry but only if SuseFirewall2 has been turned off.

Setting up for Sharing: Now I will discuss HowTo set up Samba shares so network drives will function correctly once the shares are mapped/mounted in a Linux client machine. There are essentially three commonly used categories to consider. Shares that you address as part of the machine’s filesystem through network drives are configured subtly differently from shares thet you address through a network file browser.

KDE on-the-fly Shares: These are made in Konqueror file browser with a R-click –> “Share”. This opens a GUI with configuration options. Enabling and using this facility in KDE is discussed in detail in a companion tutorial. For the current exercise it’s important to change the permissions on the shared folder that I’ve called “origin”. Origin’s default permissions are rwr-r-. You must change them to rwrwrw. When the share is mounted as a mapped drive on the client, the destination folder acquires identical mapped permissions rwrwrw. Consequently any user on the client machine will have read/write access to the network drive at /home/username/destination.

Be careful to use the correct case in the text you use to mount the share using either command line or an entry in fstab. You see, these on-the-fly shares made in Konqueror appear in the network in capital letters, despite the case of the folder that is being shared. So you must use “ORIGIN” rather that “origin” when mounting the network drive.

Nautilus on-the-fly Shares: These are quite similar to Konqueror’s on-the-fly shares. But the underlying technology is very different. These so-called usershares are created in Nautilus file browser with a R-click –> “Sharing Options”. This opens a GUI with configuration options. Enabling and using this facility in Gnome is discussed in detail in a companion tutorial. The Gnome programmers have included behind the scenes programming that changes the shared folder’s permissions to rwrwrw. When the share is mounted as a mapped drive on the client, the destination folder acquires identical mapped permissions rwrwrw. Consequently any user on the client machine will have read/write access to network drive at /home/username/destination.

Secure Classical Shares: These shares are made by root, using a text editor to insert the configuration for a share into the Samba configuration file at /etc/samba/smb.conf. There are two very common read/write configurations. This is one of them:

and here is the other frequently-used form:

[origin]
path = /home/user_on_server/origin
read only = no
force group = users
force user = user_on_server

The appropriate permissions for the shared folder “origin” are rwrw–. These permissions map across to the “destination” folder on the client. Consequently the shared files are read/write accessible to any user logged onto the client machine. This is less restrictive/secure than the share would be if it was not mounted. That’s a consequence of the process.

If you wish to restrict the access absolutely, you can create focus with a common user. Suppose for a moment that netuser is common to both the client and the server machines. Establish the share at /home/netuser/origin on the client and give it permissions rw—-. Establish the destination folder at /home/netuser/destination on the client. Make the share’s definiton like this in smb.conf:

[origin]
path = /home/netuser/origin
valid users = netuser
read only = no

Use this variation (all one line) in fstab to effect mounting during boot, being careful to use netuser’s uid:

//192.168.44.100/origin /home/netuser/destination cifs 
username=netuser,password=hiddenword,auto,uid=netuser,gid=users 0 0

This mapped drive on the Suse client will be restricted to netuser alone.

Be as well as you can
Swerdna: 27 April 2007