Two methods, depending on share host
smbfs is the "original" method.
However, smbfs is not compatible with security signatures, which are enabled by default and not recommended to disable on Windows Server 2003 and later. If a share is served by Windows Server 2003 or later, you should use cifs.
Prerequisites
You must have a windows machine (or other machine running Samba) with an accessible share.
The 'samba' package itself is not necessary if you only need a smb client.
The "smbfs" package provides the tools needed to mount "smbfs" and "cifs" filesytems. You may have smbfs installed on your machine. If not, run
sudo apt-get install smbfs
Update the unmount order to prevent CIFS from hanging during shutdown.
sudo update-rc.d -f umountnfs.sh remove
sudo update-rc.d umountnfs.sh stop 15 0 6 .
Setup
Single User
Note the UID of the single user which is to have access to the share. For a user named $username, the following command outputs the UID
grep $USERNAME /etc/passwd | cut -d: -f3
Multiple Users
If multiple users are to have the same level of access to the share, then create a new user group, presumably named after the share.
Navigate to "System" -> "Administration" -> "Users and Groups" -> "Manage Groups". -> "Add Group" and select a name, Group ID (GID), and group members. Note the GID -- you will need it later.
Credentials File
Warning- this method is not completely secure, any user with root access could see your password in plain text.
Create a file called .smbcredentials, probably in the home directory of the primary user of the share. In this file put username an equals sign and the windows username (and domain if loging into a domain) on the first line, put password an equals sign and the password for that user account on the second line of the file. The file should look like:
username=MyUsername
password=MyPassword
# OR:
# username=MyUsername@MyDomain
# password=MyPassword
# OR: (for cifs on Windows Serve 2003)
# username=MyDomain/MyUsername
# password=MyPassword
On the command line, in the directory of .smbcredentials type
sudo chown root .smbcredentials
sudo chmod 600 .smbcredentials
this will ensure that only root can access this file.
Note: Regretfully as from version 3.3.2-1ubuntu3.2 (October 2009) this approach is no longer possible together with the "user" option. A security fix prevents reading the credentials file if you don't have read access to it. You will have to pin the packages at version 3.3.2-1ubuntu3 or 3.3.2-1ubuntu3.1 to continue using this approach as non-root.
Editing fstab
Warning- editing the fstab file can be dangerous, please back it up before continuing.
Note: if servername or sharename has a literal space (i.e. ' '), substitute \040 instead, so that 'server name' becomes 'server\040name'
Add a line at the bottom of your /etc/fstab file that specifies:
//$SERVER/$SHARE $MOUNTPOINT $FS_TYPE credentials=$SMB_CREDENTIALS,uid=$UID,gid=$GID
# e.g.
SERVER=apollo
SHARE=install_files
MOUNTPOINT=/path/to/mnt
FS_TYPE=smbfs
SMB_CREDENTIALS=/path/to/.smbcredentials
UID=1000
GID=1000
smbfs, group perms
- FS_TYPE=smbfs
- GID=1234 # the newly created group's ID
- don't include uid=$UID, which defaults to that of root
//apollo/install_files /path/to/mnt smbfs iocharset=utf8,credentials=/path/to/.smbcredentials,gid=1234 0 0
Note: many directories are set so that only the user can write to the directory and that the group can only read (permissions 0755), if this is the case then when it is mounted the group will still not be able to write to the directory regardless of their permission on the share. To give the group write permissions on the mount then use the following.
//apollo/install_files /path/to/mnt smbfs iocharset=utf8,credentials=/path/to/.smbcredentials,dir_mode=0775,gid=1234 0 0
smbfs, user perms
- FS_TYPE=smbfs
- UID=1000 # particular user's uid
- don't include gid=$GID, which defaults to $UID
//apollo/install_files /path/to/mnt smbfs iocharset=utf8,credentials=/path/to/.smbcredentials,uid=1000 0 0
cifs, group perms
- FS_TYPE=cifs
- GID=1234 # the newly created group's ID
- don't include uid=$UID
//apollo/install_files /path/to/mnt cifs iocharset=utf8,credentials=/path/to/.smbcredentials,gid=1234 0 0
Note: many directories are set so that only the user can write to the directory and that the group can only read (permissions 0755), if this is the case then when it is mounted the group will still not be able to write to the directory regardless of their permission on the share. To give the group write permissions on the mount then use the following.
//apollo/install_files /path/to/mnt cifs iocharset=utf8,credentials=/path/to/.smbcredentials,dir_mode=0775,gid=1234 0 0
cifs, user perms
- FS_TYPE=cifs
- UID=1000 # the user's uid
- don't include gid=$GID
//apollo/install_files /path/to/mnt cifs iocharset=utf8,credentials=/path/to/.smbcredentials,uid=1000 0 0
Ensure
- The entire expression MUST all be on one line in your fstab file
- use "//" and "/" instead of "\\" and "\" when specifying the share location
- /path/to/mnt is a directory that exists (and is empty)
Completing Setup
Reload fstab:
sudo mount -a
Troubleshooting
cifs will not mount
Note:- cifs by default does not resolve netbios names so you may get an error message when you try to mount that the name could not be resolved into an address and "could not find target server". In order to enable netbios resolution you need to edit /etc/nsswitch.conf and add the winbind package:
sudo gedit /etc/nsswitch.conf
change the line from
hosts: files dns
to
hosts: files wins dns
sudo aptitude install winbind
Now you should be able to mount the directory.
Note: If you experience slow dns resolution after making these changes, you can change the order of the entries to the following and you may see an improvement.
hosts: files dns wins
Server is down, filesystem is hung
If the client somehow loses contact with the Samba server, then the filesystem will probably get hung. Basically, it becomes a blackhole, eating things that try to read to/write from it (e.g. ls) and refusing to go away (e.g., umount says that the "device is busy").
Sometimes, all you need to do is restart the Samba daemon on the server machine.
sudo /etc/init.d/samba restart
If that doesn't work, or for some reason you can't do anything on the server side, then try
sudo umount -lf /mount/point
The -f option forces (possibly unclean) unmounting, and the -l option is for "lazy unmounting", and seems to work around "device is busy" errors that occur with just -f.
CIFS remote ownership enforcement
When you connect using CIFS to a server which supports Unix permissions (e.g. Samba), CIFS will by default try to enforce remote Unix ownership UIDs and Unix permissions when you try to access the share. i.e. if a file is owned by UID 502 on the remote server, then the local kernel will try to enforce the same permissions if it were owned by UID 502 on the local machine. Note: This has nothing to do with the remote server's security settings. This is an extra local ownership enforcement by the filesystem driver. It is a feature to allow use of remote share as a local drive with full Unix permissions enforcement if users match.
But if this is a public share, then chances are, the remote UIDs will not make sense locally. A remote UID might be a completely different user or might not exist at all on the local machine. If remote UIDs and local UIDs do not match, then local users will have trouble using the share. To disable this, use the "noperm" mount option. Remote permissions and UIDs will still be visible, but they will not be enforced locally.
System Hangs on Shutdown
Sometimes during shutdown, networking will be turned off before the network share is unmounted. This will cause the computer to display the below code for a few minuets before shutting down (the numbers seem to change after each boot).
CIFS VFS: server not responding
CIFS VFS: no response for cmd ## mid ###
To fix this problem, and allow the computer to shut down smoothly, just change when the network share is unmounted by the file system. This can be done by running the following commands:
sudo update-rc.d -f umountnfs.sh remove
sudo update-rc.d umountnfs.sh stop 15 0 6 .
Login without Credentials
If you want to mount the share without the credentials file you can use the entry below. I believe that by adding the _netdev in the entry below, it will not mount the share if you are not connected to the same network that the share is on or if you are not connected to a network at all.
- # /etc/fstab: static file system information. #
# <file system> <mount point> <type> <options> <dump> <pass>
//<server>/<share> <mount point> cifs rw,_netdev,user=<username>,password=<password>,uid=<uid>,gid=<gid> 0 0
Here is an example of the last line //gurnee/projects /home/jcrow/GurneeServer cifs rw,_netdev,user=DOMAIN/user,password=password,uid=1000,gid=100 0 0
The server being connected to is Gurnee, the shared folder is projects, the mount point is /home/jcrow/GurneeServer
Connect when network available
The
_netdev option is also used for systems that only have networking started at user login (as when using the Gnome Network Manager package). For having network connections enabled at boot up (without requiring a user login) then tools that write to the /etc/network/interfaces file may have to be used. It is probably good policy to always use
_netdev for all automatic network mounts.
