Creating a Common Shared Directory for Virtual Machines and Trusted Users on a LAN

sh002A previous article, Local File Sharing in Linux, provided a way for local users on the same Linux computer to share files among themselves where each user viewed himself as the owner of the file. There are other ways to achieve similar results, but given the objectives, this technique worked well.

However, that works well for local users. What about extending the access to networked users on the same LAN? How about providing a common shared directory so Linux and Windows virtual machines can share files among themselves?

VirtualBox is a popular virtualization program that has a built-in folder sharing feature that allows the guest (the OS running inside VirtualBox) operating system to access host (the system on which VirtualBox is running) directories without using a network connection. This option is found in the VirtualBox menubar Devices > Shared Folders, and it allows the guest direct access to host files even if the network cable is disconnected.

This works well with a Windows guest, but a Linux guest is a little trickier to configure. Yes, VirtualBox provides the vbox server for Linux and it does provide direct access to host directories, but there have been issues with Linux. In the end, other networking technologies, such as SSH, FTP, and Samba, are easier to configure and maintain for Linux (guest)-to-Linux (host) file transfers through VirtualBox. This article covers how to handle Linux (guest)-to-Linux (host) file sharing without using the vbox server.

The public shared directory presented in this article must meet certain objectives:

  • One specific shared directory located on the host.
  • Accessible by any user/virtual machine connected to the network.
  • No username/password needed. Simply enter the shared IP address to connect.
  • Any user may create/modify/delete any other user’s files and directories.
  • User access is restricted to the shared directory.

These items are not recommended for use on a public network whose user reputations are questionable, but this level of freedom is fine for a trusted private network where users and virtual machines trust each other and are guaranteed to be the only users.

This article shows how to set up this arrangement implementing Samba on Linux Mint 15, though other Linux distributions should work as well. There are separate steps that must be configured on the host and for the guests.

The Host Side of Things

The host requires the most involving part of the setup. Once complete, any remote system on the LAN, including virtual machines, can connect to the shared directory residing on the host.

1. Install Samba

Samba is a subject all of its own, so Samba installation is not discussed here. To reduce article length, this article assumes Samba is already set up an running.

While other protocols, such as FTP, will work, we are using Samba because it offers minimal configuration to produce the intended results. For one, Samba users are restricted to shared directory. This means users cannot traverse the host filesystem and explore the host files. This adds privacy to the arrangement.

Yes, FTP can be configured to do the same, but its configuration depends upon the chosen FTP server and often requires more configuration tweaking.

SSH is better suited for secure remote logins, but we do not want to allow logins using the dedicated share user produced in this example. While it is possible to restrict an SSH login to a specific directory by implementing a chroot jail, setting up the jail is a tricky, involving process. Samba is easier and quicker.

We will configure Samba for the shared directory later. For now, just install Samba, and make sure it runs without errors.

2. Install bindfs

sudo apt-get install bindfs

This handles all permissions and allows each user to have full access to each file and directory located in the shared directory.

3. Create a Dedicated share directory

sudo mkdir /var/public_share

This is the directory that all users (local or remote) and all virtual machines will have full read/write access to. Create it outside of any user’s home directory. The /var directory is good place to store it.

If we had placed this inside a user’s directory, we would need to wait for the user to log in before allowing anyone access to it if home encryption is enabled. Also, the user’s home permissions might be set to deny any non-owners, and this would pose another access restriction. We do not want the shared directory to be dependent upon any user, so it must exist at the system level.

4. Create a Dedicated share Group

sudo groupadd share

Add each local user (on the host) who needs access to the shared directory to this group.

sudo usermod -aG share <username>

<username> is the login username of the user on the host to add to the share group. If a user is already logged in to the system while added to group, then he must log out and log back in for the changes to take effect. Otherwise, the system will not see him as a member of the share group yet.

5. Create a Dedicated share User

Users and Groups in System Settings is the easiest way to do this, but we want to limit the user’s home directory to that of the shared directory, so let us enter this in a terminal:

sudo useradd share -g share -M -d /var/public_share

This adds a new user to the system named share, assigns share to the group named share, does not create a home directory (-M) for user share, and assigns the home directory as the shared directory /var/public_share (-d).

When we use bindfs, all users will be seen as the share user belonging to the share group. This is how different users can modify any files. They will all be seen as the same user.

For users that already exist, they can be added to the share group one at a time.

sudo usermod -aG share <username_to_add>

6. Lock the share Account

We do not want to allow logins as the share user, so lock the share account on the host.

sudo usermod -L share

If a user can log in using SSH, then he can traverse the host directory. Even if account share is locked and cannot log in locally or remotely, users can still access the shared directory through the Samba server.

7. Change share Ownership

sudo chown root:share /var/public_share

This is more for recognition than function since bindfs will mask the ownership with that of its own.

8. Change the Shared Directory Permissions

sudo chmod 0777 /var/public_share

Yes, this grants full access to everyone. We need the 777 so virtual machines, which are treated as remote networked machines, can automatically mount the share from their /etc/fstab files at boot-up using smbfs, and smbfs cannot mount them if it does not have read/write access for everyone. Otherwise, errors appear.

9. Create a Shared Help File

This is a text file located inside the shared directory with an explanation and instructions for users. It can be anything informative, but let’s keep it simple for this example.

+ Welcome to the Public Share! +
| Any file may be accessed     |
| by any other user. Have fun! |

(For those desiring fancy text, programs such as toilet and figlet are friends.)

Save it as a filename that gives a clue about its purpose. For compatibility with Windows, include a relevant file extension, such as .txt. Keep in mind that this share is not Linux-specific. Other operating systems may access it, and they need to know how to handle file types.

Making the File Immutable

There is one problem here. This file file must be available to all users and remain unaltered and unchangeable lest a wisecrack user replace it with jokes or scare tactics. However, any file can be deleted or modified inside the shared directory. So, how can we protect this file?

We can do this by setting the immutable attribute on the file so nobody, not even root, can delete or alter its contents.

sudo chattr +i help.txt

This makes the file immutable so it cannot be deleted locally or remotely. To alter the file, only the host’s root user may do so by first removing the immutable attribute.

sudo chattr -i help.txt

Once the changes have been made, set the immutable attribute again.

lsattr will list file attributes, which are different from file permissions. lsattr will produce terminal output similar to this from /var/public_share:

----i--------e-- ./help.txt

Where i means that the immutable attribute is set, and the file cannot be altered in any way.

Troubleshooting chattr

File attributes cannot be changed while the shared directory is mounted. Any attempt to use chattr +/-i while mounted produces this error:

chattr: Function not implemented while reading flags on /var/public_share/help.txt

Stop Samba and unmount bindfs in order (shown later) to change the file attribute.

/var/public_share in summary:

Owner: root

Group: share
(For recognition so we can see that it belongs to the share group. This does not limit access to the share group only because we must set others as rwx so smbfs will mount it remotely.)

Others: rwx permissions
(Remote virtual machines using smbfs will not mount the shared directory if this is set to read-only.)

10. Configure Samba

Open the Samba configuration file. Depending upon the Samba version installed, the configuration file might be located in other places, but try /etc/samba/smb.conf.

Add this following directives somewhere in smb.conf where shares are specified.

 comment = Common share directory granting full access
 path = /var/public_share
 guest ok = yes
 browseable = yes
 read only = no
 writeable = yes
  • [public_share]: The name of the share that appears in Windows listings.
  • comment: Anything that describes the share point.
  • path: Absolute path to the shared directory on the host.
  • guest ok: Allows anyone access without using a username and password.
  • browseable: Allows users to browse within shared directory structure but not above it.
  • read only/writable: Allows user to write to and delete files. Essential for this purpose.

Testing the Host Setup

That is all for the host configuration. The steps take time, but this is a process we only need to do once. Now, let’s test it to make sure we can access the shared directory through Samba.

In a terminal, mount the shared directory using bindfs.

sudo bindfs -o perms=0777,owner=share,group=share /var/public_share /var/public_share

Bindfs offers a plethora of features to customize control. This example is very simple: Give everyone full access as the host’s share user, who is a member of the host’s share group.

Please read man bindfs for a wealth of customization details.

Also note that we are mounting the shared directory in itself. This is intentional so we do not need to create a separate mount point, though that is allowed.

An ls -l of /var at this point will show that /var/public_share is owned by share, not root as before. This shows that bindfs is working.

Next, open Nemo, Thunar, Nautilus, or whatever file manager is available on the host, and enter the IP address of the host in the location bar along with the smb protocol. Or use localhost,, or the hostname. All paths should lead to the same place and display the Samba shared directory.

smb:// (Assuming this is the IP address of the host. Will vary.)
smb://tiger_machine2 (tiger_machine2 is the hostname of the host)

Any of the above should work. If one times out, then try another. Usually, the IP address is the most reliable if networking is set up properly and functioning on the host, and this is what remote machines and virtual machines will use to connect.

If all went well, public_share should appear in the file manager, and the title bar will read something like “Windows shares on tiger_machine2” where the hostname will be replaced with the hostname of the host hosting the share.


Testing localhost. The public share appears normally.

Now, try to create new files and directories (and delete them) within the current file manager. If this succeeds, then everything was set up correctly on the host, and remote users and virtual machines will be able to do the same.

When deleting, keep in mind that there is no trash can for a Samba share, so any deletions will be permanent.


Take care when deleting from a Samba share. There is no recover option.

Troubleshooting and Unmounting

If something went wrong and the setup must be configured or experimented with, stop Samba and then unmount the shared directory in that order:

sudo service smbd stop
sudo fusermount -u /var/public_share


sudo umount /var/public_share

Any attempt to unmount bindfs while Samba is sharing it will produce this error message:

fusermount: failed to unmount /var/public_share: Device or resource busy

To be safe, make sure any windows or file transfers involving Samba are closed before attempting to stop the Samba service.

Any changes to the Samba share, such as renaming the share or modifying its directives, will require a Samba restart.

Once changes have been made, start Samba and mount bindfs.

Automounting with fstab

After the share directory is confirmed working, we can automount bindfs at boot time by modifying /etc/fstab.

sudo gedit /etc/fstab

Add this line:

bindfs#/var/public_share /var/public_share fuse perms=0777,owner=share,group=share 0 0

This is the same as the standalone command but with a few modifications for /etc/fstab. Now, the shared directory will be mounted with bindfs and ready for use assuming Samba also starts at system boot-up.

The Remote Side of Things

Each virtual machine must be set up as part of the LAN. Assign each its own IP address if DHCP is not being used and ensure that the VirtualBox network adapter has its cable connected. (The host should have a static IP address, if possible.)

The guest’s adapter should be set to bridged. Full details are available in the VirtualBox Network preferences. The host and guest should be able to ping each other from anywhere on the LAN.

Testing the Virtual Machine (Linux)

This is the same test that was performed on the host. In a Linux file manager, such as nautilus, Thunar, or Nemo, enter the IP address or the hostname of the host containing the shared directory.

smb://tiger_machine2 and localhost cannot be used. Otherwise, the guest would be attempting to access itself.


Connecting to the host using the IP address alone shows the public_share directory. Users are limited to the contents and subdirectories of public_share. No one can explore the filesystem of the host outside of public_share.


Xubuntu 13.10 guest in VirtualBox. Shows the public_share connected by entering the host IP address in the location bar.

Try to create, delete, and modify files in the share. Open modified files from within another virtual machine or from the host to read the modified contents. If these steps succeed, then the arrangement is functioning properly.


Creating a “New Empty File” in virtual Xubuntu. The file is accessible to anyone who connects to the shared directory public_share. Others users may edit it or even delete it.

Again, keep in mind that deleting a file from the shared directory is permanent. There is no trash bin for recycling even if a .Trash file exists.

Testing the Virtual Machine (Windows)

The process is similar for Windows (this test uses Windows XP), but the location bar syntax is different from that of Linux. Inside a Windows virtual machine (or real machine), open Windows Explorer and enter two backslashes followed by the IP address of the host containing the shared directory.


Hostnames, such as \\tiger_machine2 will also work, but it might take time to propagate the hostname before Windows will recognize it. The host’s IP address allows for the most immediate access.


The shared directory as seen in Windows XP. Filename extensions are important so Windows can recognize file types that Linux understands intuitively. Hidden dot files, such as .face, only appear if Windows is configured to show hidden files.

“Printers and Faxes” might also appear, but that is due to the default Samba configuration.


public_share visible in Windows Explorer.

Windows Explorer should show the same files viewed from within a Linux guest. In addition, Windows will show dotted hidden files if Tools > Folder Options > View tab > Show hidden files and folders is selected.

Any new files created from within Windows will be available to Linux virtual machines and remote users. In fact, any file can be shared with anyone on the network by placing it in the public shared directory. In this way, virtual machines and private LAN users have a common location from which share files among themselves.

Automounting the Shared Directory (Linux)

There is no need to do anything more on the remote/guest side of things. Any guest can access the shared directory as it stands, but we can make the shared directory easier to access by editing /etc/fstab in the guest to automount the Samba share when the guest boots up. In some Linux distributions with a GUI, the mounted share will automatically appear on the desktop, and file manager bookmarks can be created.

This must be performed on each Linux guest.

1. Create a Mount Point

In the guest, create a directory that will serve as the mount point for the shared directory.

sudo mkdir /media/public_share

Once the shared directory is mounted, accessing this directory will be the same as accessing the Samba share directly. This provides two ways to access the same thing. Also, this allows access to the share using a terminal.

2. Edit /etc/fstab

sudo gedit /etc/fstab

(If gedit is not available, use another text editor, such as nano, vi, mousepad, or whatever is present.)

Add this line to the end of /etc/fstab:

// /media/public_share cifs defaults,username=share 0 0

Replace the with the real IP address of the host computer. /media/public_share is the mount point we created in the previous step.

3. Test

Test that /etc/fstab is correct by running this command in a terminal:

sudo mount -a

If the Linux guest is allowed to show mounted volumes on the desktop, then the share should appear automatically. If not (or even if it does), open a file manager and enter /media/public_share in the location bar. The contents of the remote shared directory should appear.

4. Create a Soft Link

Bookmarks and symbolic links are handy, but we cannot create them to point to Samba shares. So, we create a soft link that points to the mount point of the Samba share. In this case, it is /media/public_share. Assume that a terminal is opened on the desktop in a guest virtual Xubuntu and we enter this command:

ln -s /media/public_share public_share

This creates a link on the desktop (in the user’s Desktop directory) that points to the mount point /media/public_share. Opening the link opens the mount point, which opens the mounted shared directory.

Note: Be careful that a share link is not created when one already exists in the current path as the newly created link or else it will be added at the last point in the path within itself, not overwriting the desktop link as expected. Sound confusing? This is an unexpected, odd behavior that must be seen to be believed, but it happens. It is logical Linux behaving properly, but the result produces something like ../public_share/public_share/public_share/public_share/public_share/…

Also Note: If Conky is running, mounted volumes and links might not appear on the desktop even though they appear in the directories they are created.

To remove a symbolic link, enter the following command in the directory containing the link.

rm public_share

Link Access Summary

smb:// <--- Cannot create a soft link to this

/media/share <--- Can create a soft link to this

Automounting the Shared Directory (Windows)

In Windows, it is a little different because we must map the shared directory as a network drive. This test uses Windows XP, but all versions of Windows follow a similar technique.

Open the Map Network Drive dialog (Open Windows Explorer and go to Tools > Map Network Drive).


Windows Explorer showing the Map Network Drive menu item.

Choose a drive letter, and click the Browse button to open a list of servers available on the network. In this case, S: is chosen.


Drive S: will represent the shared directory in Windows XP.

Samba defaults to WORKGROUP, so expand the Workgroup list, find the host computer, expand the host computer list, and choose the public_share folder. Click OK. Click Finish.


public_share appears in the Windows Workgroup.

The shared directory appears as a shared drive in My Computer. If the share was set to reconnect at login, then the drive will automatically mount when the virtual Windows boots.


public_share now appears in My Computer in Windows Explorer. If set to reconnect at login, it will automatically appear.


Double-clicking drive S: shows the contents of the share. Windows adds plenty of connection information in its address bar.


Deleting Immutable Files in Windows

Remember the help.txt file that was set to immutable? No user can delete it. If there is an attempt to delete the immutable file, Linux will ask for confirmation to delete as it would for any other file, but it will return a permission denied error and leave the file alone.


An attempt to delete the immutable help.txt file in the Xubuntu guest. The delete confirmation appears normally, leading us to believe that the file can be deleted.


However, this error is returned. Immutable files cannot be deleted.

In Windows, the story is different. If “deleted,” Windows will remove the filename without any confirmation from the share in Windows Explorer, but the file will reappear if the Explorer window is refreshed. The file persists. This is minor, but it might cause some people to believe that the file has been deleted when it actually has not.


Windows XP. We are going to try to delete the immutable help.txt file.


The file disappears from Windows Explorer. It looks like the file has been deleted.


What’s this? Refreshing Windows Explorer shows the file again. No error messages given as with Linux.



After using this system for a while, it has turned out to be remarkably reliable. The setup might be involving, but once adjusted and working properly, it can be forgotten about. All that is needed is to remember how to connect to the share from a remote or virtual machine.

Note that Samba does not encrypt data, so all data transfers are performed in the clear. Of course, this sharing mechanism is meant to be used on a trusted LAN among virtual machines and trusted networked users who need full access to each other’s files through a common share point, and for that it does well.

, , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: