A 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:
Where i means that the immutable attribute is set, and the file cannot be altered in any way.
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:
(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.
[public_share] 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, 127.0.0.1, or the hostname. All paths should lead to the same place and display the Samba shared directory.
smb://localhost smb://127.0.0.1 smb://192.168.33.27 (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.
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.
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.
127.0.0.1 and localhost cannot be used. Otherwise, the guest would be attempting to access itself.
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.
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.
“Printers and Faxes” might also appear, but that is due to the default Samba configuration.
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:
//192.168.33.27/share /media/public_share cifs defaults,username=share 0 0
Replace the 192.168.33.27 with the real IP address of the host computer. /media/public_share is the mount point we created in the previous step.
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.
Link Access Summary
smb://192.168.33.27/public_share <--- 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).
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.
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.
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.
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.
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.
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.