Tag: network shared folder

How to Set Up a shared folder using Samba on Ubuntu with auto mount

How to Set Up a shared folder using Samba on Ubuntu with auto mount


One of the most popular questions long-time Linux users have been asked is, “How do I create a network share that Windows can see?

The best solution for sharing Linux folders across a network is a piece of software that’s about as old as Linux itself: Samba.

In this guide, we’ll cover how to configure Samba mounts on an Ubuntu 14.04 server.


For the purposes of this guide, we are going to refer to the server that is going to be sharing its directories the host and the server that will mount these directories as the client.

In order to keep these straight throughout the guide, I will be using the following IP addresses as stand-ins for the host and server values:

  • Host:
  • Client:

You should substitute the values above with your own host and client values.

Download and Install the Components

Samba is a popular Linux tool, and chances are you already have it installed. To see if that’s the case, open up a terminal and test to see if its configuration folder exists:


$ ls -l /etc/samba

If Samba hasn’t been installed, let’s install it first.


$ sudo apt-get update
$ sudo apt-get install samba

Configuring network share on host

Set a password for your user in Samba


$ sudo smbpasswd -a <user_name>

Note: Samba uses a separate set of passwords than the standard Linux system accounts (stored in /etc/samba/smbpasswd), so you’ll need to create a Samba password for yourself. This tutorial implies that you will use your own user and it does not cover situations involving other users passwords, groups, etc…

Tip1: Use the password for your own user to facilitate.

Tip2: Remember that your user must have permission to write and edit the folder you want to share. Eg.:

$ sudo chown <user_name> /var/opt/blah/blahblah
$ sudo chown :<user_name> /var/opt/blah/blahblah

Tip3: If you’re using another user than your own, it needs to exist in your system beforehand, you can create it without a shell access using the following command:

$ sudo useradd USERNAME --shell /bin/false

You can also hide the user on the login screen by adjusting lightdm’s configuration, in /etc/lightdm/users.conf add the newly created user to the line :


Create a directory to be shared


$ mkdir /home/<user_name>/<folder_name>

After Samba is installed, a default configuration file called smb.conf.default can be found in /etc/samba. This file needs to be copied to the same folder with the name of smb.conf, but before doing this, it’d be worth running the same ls -l /etc/samba command as above to see if your distro has that file there already. If it doesn’t exist, it’s as simple as entering sudo (or sudo -s to retain escalated privileges for the time-being, or su for systems without sudo) and making use of the default file:


$ cp /etc/samba/smb.conf.default /etc/samba/smb.conf

Make a safe backup copy of the original smb.conf file to your home folder, in case you make an error


$ sudo cp /etc/samba/smb.conf ~

Edit file /etc/samba/smb.conf


$ sudo nano /etc/samba/smb.conf

Once smb.conf has loaded, add this to the very end of the file:


path = /home/<user_name>/<folder_name>
valid users = <user_name>
read only = no

Tip: There Should be in the spaces between the lines, and note que also there should be a single space both before and after each of the equal signs.

The [Share Name] is the name of the folder that will be viewable after entering the network hostname (eg: \\LINUXPC\Share Name). The path will be the Linux folder that will be accessible after entering this share. As for the options, there are many. As I mentioned above, the smb.conf file itself contains a number of examples; for all others, there’s a huge page over at the official website to take care of the rest. Let’s cover a couple of the more common ones, though.

guest ok = yes
— Guest accounts are OK to use the share; aka: no passwords.
guest only = yes
Only guests may use the share.
writable = yes
— The share will allow files to be written to it.
read only = yes
— Files cannot be written to the share, just read.
force user = username
— Act as this user when accessing the share, even if a different user/pass is provided.
force group = groupname
— Act as this usergroup when accessing the share. username = username, username2, @groupname
— If the password matches one of these users, the share can be accessed.
valid users = username, username2, @groupname
— Like above, but requires users to enter their username.

Here are a couple of example shares I use:

The force user and force group options are not go-to options, so I’d recommend trying to create a share without them first. In some cases, permission issues will prevent you from writing to certain folders, a situation I found myself in where my NAS mounts and desktop folder were concerned. If worse comes to worse, simply add these force options and retest.

Each time the smb.conf file is edited, Samba should be restarted to reflect the changes. On most distros, running this command as sudo (or su) should take care of it:


$ /etc/init.d/samba restart

For Ubuntu-based distros, the service command might need to be used. As sudo:


$ sudo service smbd restart

If neither of these commands work, refer to your distro’s documentation.

Once Samba has restarted, use this command to check your smb.conf for any syntax errors


$ testparm

With Samba all configured, let’s connect to our shares!

Connect to Samba Network Share from clients

Once a Samba share is created, it can be accessed through applications that support the SMB protocol, as one would expect. While Samba’s big focus is Windows, it’s not the only piece of software that can take advantage of it. Many file managers for mobile platforms are designed to support the protocol, and other Linux PCs can mount them as well.

To access your network share from your desktop client, use your username (<user_name>) and password through the path smb://<HOST_IP_OR_NAME>/<folder_name>/ (Linux users) or \\<HOST_IP_OR_NAME>\<folder_name>\ (Windows users). Note that <folder_name> value is passed in [<folder_name>], in other words, the share name you entered in /etc/samba/smb.conf.

We’ll take a more detailed look at a couple of different solutions for accessing our Samba shares.

Connect to Samba Network Share from Windows client

First things first: The Microsoft side. In Windows, browsing to “Network” should reveal your Linux PC’s hostname; in my particular case, it’s TGGENTOO. After double-clicking on it, the entire list of shares will be revealed.

Network shares are all fine and good, but it’s a hassle that to get to one, it requires a bunch of clicking and waiting. Depending on Windows’ mood, the Linux hostname might not even appear on the network. To ease the pain of having to go through all that again, mounting a share from within Windows is a great option. For simple needs, a desktop shortcut might provide quick enough access, but shortcuts by design are quite limited. When mounting a network share as a Windows network drive, however, it acts just as a normal hard drive does.

Mounting a Samba share as a network drive is simple:


$ net use X: \\HOSTNAME\Share
$ net use X: “\\HOSTNAME\Share Name”

Quotation marks surrounding the entire share is required if there’s a space in its name.

A real-world example:

Connect to Samba Network Share from Linux client

Install smbclient


$ sudo apt-get install smbclient

List all shares:


$ smbclient -L //<HOST_IP_OR_NAME>/<folder_name> -U <user>



$ smbclient //<HOST_IP_OR_NAME>/<folder_name> -U <user>

Mounting a Samba Network Share from Linux client

You’ll need the cifs-utils package in order to mount SMB shares:


$ sudo apt-get install cifs-utils

After that, just make a directory…


$ mkdir ~/Desktop/Windows-Share

… and mount the share to it.


$ mount -t cifs -o username=username //HOSTNAME/Share /mnt/location

For example


$ sudo mount.cifs //WindowsPC/Share /home/geek/Desktop/Windows-Share -o user=geek

Using this command will provide a prompt to enter a password; this can be avoided by modifying the command to username=username,password=password (not great for security reasons).

In case you need help understanding the mount command, here’s a breakdown:

$ sudo mount.cifs – This is just the mount command, set to mount a CIFS (SMB) share.

WindowsPC – This is the name of the Windows computer.  Type “This PC” into the Start menu on Windows, right click it, and go to Properties to see your computer name.

//Windows-PC/Share – This is the full path to the shared folder.

/home/geek/Desktop/Windows-Share – This is where we’d like the share to be mounted.

-o user=geek – This is the Windows username that we are using to access the shared folder.

I recommend mounting the network share this way before inputting it into /etc/fstab, just to make sure all is well. Afterwards, your system’s fstab file can be edited as $ sudo (or su) to automatically mount a share at boot.

Adding values for a network share to fstab isn’t complicated, but making sure they’re the correct values can be. Depending on the network, the required hostname might have to be the text value (TGGENTOO), or an IP address ( Some trial and error can be expected, and at worst, a trip to your distro’s website might have to be taken.

Here are two examples of what could go into an fstab:

// /mnt/nas-storage cifs username=guest,uid=1000,iocharset=utf8 0 0
//TGGENTOO/Storage /mnt/nasstore cifs username=guest,uid=1000,iocharset=utf8 0 0

If a given configuration proves problematic, make sure that the Samba share can be mounted outside of fstab, with the mount command (as seen above). Once a share is properly mounted that way, it should be a breeze translating it into fstab speak.


Samba provides a quick and easy way to share files and folders between a Windows and Linux machines.

If you only want a network share between Linux machines only, you can also Set Up a Network Shared using NFS.

If you want a distributed network share with high availability and automatic replication, you can Set Up a Network Shared using GlusterFS.

Samba is said to provide the best performance for smaller files, but I haven’t done a benchmark myself so I can’t guarantee anything.

Hope you find this post helpful and get your network share running. Until next time!

How To Set Up a shared folder using NFS on Ubuntu 14.04 with auto mount

How To Set Up a shared folder using NFS on Ubuntu 14.04 with auto mount


NFS, or Network File System, is a distributed filesystem protocol that allows you to mount remote directories on your server. This allows you to leverage storage space in a different location and to write to the same space from multiple servers easily. NFS works well for directories that will have to be accessed regularly.

In this guide, we’ll cover how to configure NFS mounts on an Ubuntu 14.04 server.


In this guide, we will be configuring directory sharing between two Ubuntu 14.04 servers. These can be of any size. For each of these servers, you will have to have an account set up with $ sudo privileges. You can learn how to configure such an account by following steps 1-4 in our initial setup guide for Ubuntu 14.04 servers.

For the purposes of this guide, we are going to refer to the server that is going to be sharing its directories the host and the server that will mount these directories as the client.

In order to keep these straight throughout the guide, I will be using the following IP addresses as stand-ins for the host and server values:

  • Host:
  • Client:

You should substitute the values above with your own host and client values.

Download and Install the Components

Before we can begin, we need to install the necessary components on both our host and client servers.

On the host server, we need to install the nfs-kernel-server package, which will allow us to share our directories. Since this is the first operation that we’re performing with apt in this session, we’ll refresh our local package index before the installation:


$ sudo apt-get update
$ sudo apt-get install nfs-kernel-server

Once these packages are installed, you can switch over to the client computer.

On the client computer, we’re going to have to install a package called nfs-common, which provides NFS functionality without having to include the server components. Again, we will refresh the local package index prior to installation to ensure that we have up-to-date information:


$ sudo apt-get update
$ sudo apt-get install nfs-common

Create the Share Directory on the Host Server

We’re going to experiment with sharing two separate directories during this guide. The first directory we’re going to share is the /home directory that contains user data.

The second is a general purpose directory that we’re going to create specifically for NFS so that we can demonstrate the proper procedures and settings. This will be located at /var/nfs.

Since the /home directory already exists, go ahead and start by creating the /var/nfs directory:


$ sudo mkdir /var/nfs

Now, we have a new directory designated specifically for sharing with remote hosts. However, the directory ownership is not ideal. We should give the user ownership to a user on our system namednobody. We should give the group ownership to a group on our system named nogroup as well.

We can do that by typing this command:


$ sudo chown nobody:nogroup /var/nfs

We only need to change the ownership on our directories that are used specifically for sharing. We wouldn’t want to change the ownership of our /home directory, for instance, because it would cause a great number of problems for any users we have on our host server.

Configure the NFS Exports on the Host Server

Now that we have our directories created and assigned, we can dive into the NFS configuration file to set up the sharing of these resources.

Open the /etc/exports file in your text editor with root privileges:


$ sudo nano /etc/exports

The files that you see will have some comments that will show you the general structure of each configuration line. Basically, the syntax is something like:

directory_to_share     client(share_option1, ... , share_optionN)

So we want to create a line for each of the directories that we wish to share. Since in this example or client has an IP of, our lines will look like this:



We’ve explained everything here but the specific options we’ve enabled. Let’s go over those now.

  • rw: This option gives the client computer both read and write access to the volume.
  • sync: This option forces NFS to write changes to disk before replying. This results in a more stable and consistent environment, since the reply reflects the actual state of the remote volume.
  • no_subtree_check: This option prevents subtree checking, which is a process where the host must check whether the file is actually still available in the exported tree for every request. This can cause many problems when a file is renamed while the client has it opened. In almost all cases, it is better to disable subtree checking.
  • no_root_squash: By default, NFS translates requests from a root user remotely into a non-privileged user on the server. This was supposed to be a security feature by not allowing a root account on the client to use the filesystem of the host as root. This directive disables this for certain shares.

When you finish making your changes, save and close the file.

Next, you should create the NFS table that holds the exports of your shares by typing:


$ sudo exportfs -a

However, the NFS service is not actually running yet. You can start it by typing:


$ sudo service nfs-kernel-server start

This will make your shares available to the clients that you configured.

Create the Mount Points and Mount Remote Shares on the Client Server

Now that your host server is configured and making its directory shares available, we need to prep our client.

We’re going to have to mount the remote shares, so let’s create some mount points. We’ll use the traditional /mnt as a starting point and create a directory called nfs under it to keep our shares consolidated.

The actual directories will correspond with their location on the host server. We can create each directory, and the necessary parent directories, by typing this:


$ sudo mkdir -p /mnt/nfs/home
$ sudo mkdir -p /mnt/nfs/var/nfs

Now that we have some place to put our remote shares, we can mount them by addressing our host server, which in this guide is, like this:


$ sudo mount /mnt/nfs/home
$ sudo mount /mnt/nfs/var/nfs

These should mount the shares from our host computer onto our client machine. We can double check this by looking at the available disk space on our client server:


$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vda               59G  1.3G   55G   3% /
none                  4.0K     0  4.0K   0% /sys/fs/cgroup
udev                  2.0G   12K  2.0G   1% /dev
tmpfs                 396M  324K  396M   1% /run
none                  5.0M     0  5.0M   0% /run/lock
none                  2.0G     0  2.0G   0% /run/shm
none                  100M     0  100M   0% /run/user          59G  1.3G   55G   3% /mnt/nfs/home

As you can see at the bottom, only one of our shares has shown up. This is because both of the shares that we exported are on the same filesystem on the remote server, meaning that they share the same pool of storage. In order for the Avail and Use% columns to remain accurate, only one share may be added into the calculations.

If you want to see all of the NFS shares that you have mounted, you can type:


$ mount -t nfs on /mnt/nfs/home type nfs (rw,vers=4,addr=,clientaddr= on /mnt/nfs/var/nfs type nfs (rw,vers=4,addr=,clientaddr=

This will show all of the NFS mounts that are currently accessible on your client machine.

Test NFS Access

You can test the access to your shares by writing something to your shares. You can write a test file to one of your shares like this:


$ sudo touch /mnt/nfs/home/test_home

Let’s write test file to the other share as well to demonstrate an important difference:


$ sudo touch /mnt/nfs/var/nfs/test_var_nfs

Look at the ownership of the file in the mounted home directory:


$ ls -l /mnt/nfs/home/test_home
-rw-r--r-- 1 root   root      0 Apr 30 14:43 test_home

As you can see, the file is owned by root. This is because we disabled the root_squash option on this mount that would have written the file as an anonymous, non-root user.

On our other test file, which was mounted with the root_squash enabled, we will see something different:


$ ls -l /mnt/nfs/var/nfs/test_var_nfs
-rw-r--r-- 1 nobody nogroup 0 Apr 30 14:44 test_var_nfs

As you can see, this file was assigned to the “nobody” user and the “nogroup” group. This follows our configuration.

Make Remote NFS Directory Mounting Automatic

We can make the mounting of our remote NFS shares automatic by adding it to our fstab file on the client.

Open this file with root privileges in your text editor:


$ sudo nano /etc/fstab

At the bottom of the file, we’re going to add a line for each of our shares. They will look like this:

client    /mnt/nfs/home   nfs auto,noatime,nolock,bg,nfsvers=4,intr,tcp,actimeo=1800 0 0    /mnt/nfs/var/nfs   nfs auto,noatime,nolock,bg,nfsvers=4,sec=krb5p,intr,tcp,actimeo=1800 0 0

The options that we are specifying here can be found in the man page that describes NFS mounting in thefstab file:


$ man nfs

This will automatically mount the remote partitions at boot (it may take a few moments for the connection to be made and the shares to be available).

Unmount an NFS Remote Share

If you no longer want the remote directory to be mounted on your system, you can unmount it easily by moving out of the share’s directory structure and unmounting, like this:


$ cd ~
$ sudo umount /mnt/nfs/home
$ sudo umount /mnt/nfs/var/nfs

This will remove the remote shares, leaving only your local storage accessible:


$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda         59G  1.3G   55G   3% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            2.0G   12K  2.0G   1% /dev
tmpfs           396M  320K  396M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm
none            100M     0  100M   0% /run/user

As you can see, our NFS shares are no longer available as storage space.


NFS provides a quick and easy way to access remote systems over a network. However, the protocol itself is not encrypted. If you are using this in a production environment, consider routing NFS over SSH or a VPN connection to create a more secure experience.