• Home
• TheWeb
• Linux
• Microsoft
• SiteMap
• OpenSource
• Musings
• Recipes

If you want to cut through all the peripheral explanations you can jump straight to the pith in the two paragraphs Mounts in a Linux Client or Setting up a Linux Server.

Software: In Yast --> Software management --> cifs-mount, pam-cifs, samba-client (plus optionally kdebase3-samba if using KDE and nautilus-share if using Gnome).

The parameters/names I use in the Tutorial: Here are the parameters, names, passwords and so on that I made up for the tutorial. Refer back here when you get confused about them in the examples that follow.

Example names for the server:

• • 192.168.44.100: The IP address of the file server containing the share that will be mounted in the client.
• • server_name: The network name of the server (this is the name you see in your network browser for the server computer).
• • share_name: The network name of the share on the server.
• • server_user: The username of the owner of the shared directory on the server.
• • server_password: The password to access the share on the server. In Windows it is the login password of the share's owner. In Linux it is the Samba user's password.

Example names for the client:

• • mount_point: The directory on the client where the mapped drive is mounted. The filesystem and files for the share on the server appear in this mount.
• • /path_to/mount_point: The path to the mount in the Linux client.
• • client_username: Once the remote share is mounted, the ownership changes as designated in the mount command to a cifs owner; e.g. in this tutorial he/she is "client_username". Note that the usernames on the server and the client machines can be different, but if you wish it, they may be the same; i.e. "client_username" and "server_user" can be the same name/person.

There are two parts to this tutorial. One is how to mount shares as network drives. The other is how to structure a share on a Linux server so that clients can mount it effectively. Both are important.

↑↑↑↑Mounts in a Linux Client

Your mapped drives (AKA network drives) can be mounted either temporarily or permanently.

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 these are all-one-line):

You may use the netBIOS name of the server (e.g. server_name) in place of the IP address in the command line above. That line would then look like this (su first):

Note that these commands haven't specified an owner for the mount. For a Windows server the mount will automagically assume permissions drwxrwxrwx and the ownership will stay as the Linux owner of the directory mount_point. For a Linux server the mount will automagically assume the permissions on the share on the server and will switch ownership to match the owner on the server (which can be tricky if the owner on the server doesn't exist on the client).

If you want to prescribe the owner of the mount on the client, then use these variants:

Remember, you can user the network name //server_name instead of the IP address //192.168.44.100. You may also use numbers like uid=1002,gid=100 instead of uid=client_username,gid=users.

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:

and a KDE user opens fstab in the editor "kwrite" with this command:

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

The option _netdev is always recommended for cifs mounts in fstab. Option _netdev delays mounting until the network has been enabled.

You may also use the network name (netBIOS name) of the server (e.g. server_name) instead of the IP address in the line in fstab. But note (several paragraphs below) my description of a bug in openSUSE and a workaround if you do use the network name. With network name instead of IP address, the line in fstab looks like this:

Remember, the owner of the shared directory on the server, in this example "server_user", can be the same as or different from the cifs owner designated in the mount command to own the mounted drive, in this example "client_username".

FAQ: Hiding the Username & Password: Any Linux user on the client machine who chooses to view the file fstab can of course read the {username,password} credentials required to be sent to the server to effect the mount. If this is undesirable, you can put the credentials in a hidden file, e.g. ".creds". For additional security you can make the file ".creds" readable only by the owner (rw----). The entry in fstab then becomes:

And the contents of ".creds" are like this:

FAQ: OpenSUSE & SuSEfirewall2 bug & workaround: In openSUSE 10 and 11, if you use the netBIOS name of the server in the line in fstab instead of the IP address when the firewall is up in the client, it won't work without a workaround. It works just fine when using the IP address (//192.168.44.100/share_name) but not when using the network name (//server_name/share_name). In the case of network name addressing you need to re-instruct Suse some 10 seconds after booting to retry any failed mounts with the root command mount -a. Use the trick of the entry in crontab that I mention below for slow networks. My advice is to use the IP address to define the server where possible.

FAQ: Tricks for a Slow Network: Some users, including me, find that the mounts in fstab execute before the network is properly established. Of course, the shares simply won't mount if the network hasn't come on line. In most cases the option "_netdev" will ensure the network is up before the mount in fstab is executed. That mightn't be enough for your configuration and you may need to further delay the procedure. The extra delay is effected by setting up a cron job in the crontab(le) for the root user, whereby the command mount -a is execute approximately 10 seconds after the boot process. That command mounts all devices listed for mounting in fstab that are not already mounted. I've included a discussion of cron and crontab on this site and here's the entry you can put into root's crontab if the "_netdev" option fails to delay the mounting procedure sufficiently:

FAQ: Using OpenOffice.Org and Word Files: A mapped drive on a Windows Server will create problems with Microsoft Office/Word files being manipulated in OpenOffice Writer software on the client. The OpenOffice Writer program will freeze when the edited .doc file is saved using the "Save As" feature. This occurs because OpenOffice doesn't use the cifs-style mandatory byte range locks. The problem is fixed when you add the option nobrl into the options for the cifs mount.

FAQ: How to mount the share by network name: You can designate the address of the server two ways in the mount, by IP address or by network netBIOS name. Using the network name will only work if you have good name resolution on your Samba LAN. In my experience there are two conditions. First you must be able to browse to the share on the server in the client's network browser. Second you must be able to ping the server in a console by netBIOS name. If you can't do these two things, use the IP address in the mount command, not the network name. Big Tip: once you can browse from the client to the share on the server, you should be able to ping the server after you have added "wins" to the end of the line specifying "hosts:" in the file /etc/nsswitch.conf.

↑↑↑↑Setting up a Linux Server: There are many workable Samba shares. Some of them present complications if you mount them using the cifs filesystem. The shares that I post in this section are my recommendations for shares suitable for mounting using cifs-- so far as I know they're free of complications.

Samba User database: You need a minimum of one member of the Samba user database on the server if you want to map useful network drives; you pass those credentials to the server from the client. Suppose for this exercise we continue using the name "server_user" with password "server_password". Server_user is a real Linux user on the openSUSE computer. [Server_user can be, but doesn't have to be the owner of the shared folder "share_name". Server_user can even be a dummy without a home folder if you wish.] You add server_user to the Samba database on the server in a terminal session like this:

Unsecured Shares: Most existing shares can be mapped across to a client machine. Most of the shares that are made on-the-fly using GUI tools in openSUSE are available to anyone on the LAN, in the style of a Windows share. These are the very useful, world-writeable, guest-accessed shares. Here are two, a read-only share and a read-write share, structured in a fashion that's ideal for a cifs mount. Recall that the share appears as "share_name" in netwok browsers and is owned by "server_user" on the server. For illustration, assume the share is directory "shared_directory" located at "/path_to/shared_directory"

The typical read-only share might look like this in the samba configuration file at /etc/samba/smb.conf:

The typical read/write share should look like this:

The "force user" parameter ensures that all files and directories created in the share across the network will be owned consistently by the Linux owner of the share (server_user), thus preventing an administrative tangle. If you aren't a Samba expert, you should also adjust the permissions on the shared directory to drwxrwxrwx. That's not strictly necessary if you have the "force user" parameter active, but it's recommended for mapped drives. Then when a share is mounted on the client, the mount automagically acquires the same permissions as the original share (drwxrwxrwx).

Secure Shares: These shares always require authentication (in the mount command). They aren't available to guests and they aren't world writeable:

Here's an all purpose read-only share.

and here's its read/write equivalent:

The appropriate permissions for the shared folder "shared_directory" are drwxr-xr-x. 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 who can provide (in the mount formulation) the credentials of any Linux user who has been added to the Samba user database on the server.

If you wish to restrict the access absolutely only to one user, e.g. "server_user", make server_user the Linux owner of the shared directory and structure the share on the server like so:

Use this variation (all-one-line) in fstab to effect mounting during boot:

Be as well as you can
Swerdna: 27 April 2007; revised August 08