Share
CatchyOS-inspired Linux virtual machine with a shared folder connection

How to Add a Shared Folder to a Linux VM and Mount It Automatically After Reboot

  • November 11, 2026

Sharing a folder between your host computer and a Linux virtual machine is useful for moving files, editing code, storing downloads, and accessing the same documents from both systems.

This beginner-friendly guide explains how to create a shared folder on the host computer, expose it to a Linux VM, mount it manually inside Linux, and make it load automatically every time the VM restarts. The Linux-side procedure is similar across many distributions, including CatchyOS.

Before You Begin

  • A working Linux virtual machine
  • Administrator access inside the VM
  • A folder on the host computer that is shared with the VM
  • The share name, tag, or device name provided by your virtualization software

In the examples below, the shared folder is called shared, and it will appear inside Linux at /mnt/shared. Replace shared with the name used by your VM software if it is different.

Important: Do not copy the example mount command blindly if your hypervisor uses a different sharing method. The filesystem type and share name must match the way the host exposes the folder.

Step 1: Create a Folder on the Host

On the host operating system, create a folder that you want to share with the VM. For example, name it Linux-VM-Shared.

Add a test file to it, such as shared-test.txt. This makes it easy to confirm that the VM can see the correct folder later.

Step 2: Add the Folder to Your Virtual Machine

Open your virtualization software and select the Linux VM. Find its storage, filesystem, or shared-folder settings, then add the host folder.

  • Host path: The folder you created
  • Share name or tag: shared
  • Read-only: Disabled if the VM must create or edit files
  • Mount automatically: Optional, because this guide configures automatic mounting inside Linux

Start the Linux VM after saving the settings.

Step 3: Create a Mount Point Inside Linux

Open a terminal in the VM and create the directory where the shared folder will appear:

sudo mkdir -p /mnt/shared

A mount point is an empty directory used as the entry point for another filesystem. Verify that it exists:

ls -ld /mnt/shared

Step 4: Mount the Shared Folder Manually

The command depends on the filesystem interface provided by your hypervisor. The following example uses VirtioFS, a common method for sharing host folders with modern Linux VMs:

sudo mount -t virtiofs shared /mnt/shared

If the command succeeds, check the contents:

ls -la /mnt/shared

You should see the test file created on the host.

Create a second test file from inside the VM:

echo "Created inside the Linux VM" | sudo tee /mnt/shared/vm-test.txt

Now check the host folder. If vm-test.txt appears there, two-way sharing is working.

Alternative: A 9p Share

Some QEMU or KVM configurations expose shared folders through 9p instead of VirtioFS. In that case, the mount command may look like this:

sudo mount -t 9p -o trans=virtio,version=9p2000.L shared /mnt/shared

The tag shared must match the 9p share tag configured for the VM.

Step 5: Check the Active Mount

Use findmnt to confirm that Linux mounted the folder:

findmnt /mnt/shared

You can also check disk usage:

df -h /mnt/shared

If both commands show the share, the manual mount is working.

Step 6: Find Your Linux User ID and Group ID

Automatic mounting can sometimes make mounted files belong to root. To prepare for user-specific permissions, find your user and group IDs:

id

Look for output similar to:

uid=1000(your-user) gid=1000(your-user)

The exact numbers may differ. Keep them available if your hypervisor’s mount options support uid and gid.

Step 7: Add the Mount to /etc/fstab

The /etc/fstab file tells Linux which filesystems to mount during startup. Create a backup before editing it:

sudo cp /etc/fstab /etc/fstab.backup

Open the file:

sudo nano /etc/fstab

Add this line at the bottom for a VirtioFS share:

shared /mnt/shared virtiofs defaults,nofail,x-systemd.automount 0 0

Here is what the options mean:

  • shared: The share name provided by the hypervisor
  • /mnt/shared: The Linux mount point
  • virtiofs: The filesystem type
  • defaults: Standard mount options
  • nofail: Allows Linux to continue booting if the share is temporarily unavailable
  • x-systemd.automount: Mounts the share automatically when the directory is first accessed
  • 0 0: Excludes the share from traditional dump and filesystem-check operations

Save the file in Nano with Ctrl+O, press Enter, then exit with Ctrl+X.

/etc/fstab Example for 9p

If your VM uses 9p, use a line similar to this instead:

shared /mnt/shared 9p trans=virtio,version=9p2000.L,_netdev,nofail,x-systemd.automount 0 0

Do not add both lines for the same mount point. Use the one that matches your VM’s sharing method.

Step 8: Test the Automatic Mount Without Rebooting

Before restarting the VM, ask Linux to process the new /etc/fstab entry:

sudo mount -a

If the command returns no error, check the mount:

findmnt /mnt/shared

Then list the contents:

ls -la /mnt/shared

This test catches most /etc/fstab mistakes before they can affect the next boot.

Step 9: Restart the Linux VM

Restart the VM:

sudo reboot

After logging in again, access the mount point:

ls -la /mnt/shared

Because x-systemd.automount is enabled, the share may mount when you first access /mnt/shared rather than immediately during the earliest part of boot.

Confirm it is active:

findmnt /mnt/shared

If the host folder contents appear after reboot, automatic mounting is configured correctly.

Step 10: Improve Permissions for Normal Users

If files are readable only by root, first check the ownership and permissions:

ls -ld /mnt/shared
ls -la /mnt/shared

Some sharing methods support user and group options, such as uid=1000,gid=1000. However, these options are not accepted by every filesystem type. Add them only when supported by your virtualization software and filesystem driver.

A safer first test is to create a subfolder and check whether your regular user can write to it:

mkdir /mnt/shared/permission-test

If that command fails with Permission denied, the correct fix depends on whether permissions are controlled by the host, the hypervisor, or the guest filesystem driver. Avoid immediately changing permissions recursively.

Common Problems and Fixes

mount: unknown filesystem type 'virtiofs'

The guest may not have VirtioFS support available, or the VM may be using another sharing method. Check whether your VM should use 9p, NFS, SMB, or a hypervisor-specific driver.

mount point does not exist

Create it with:

sudo mkdir -p /mnt/shared

special device shared does not exist

The share name or tag does not match the value configured in the hypervisor. Recheck the host-side shared-folder settings.

The VM boots slowly

A share may be unavailable while the host or virtualization service is starting. The nofail and x-systemd.automount options reduce the chance of a boot failure or long boot delay.

The folder is empty after reboot

Run:

findmnt /mnt/shared

If nothing is mounted, test the entry manually:

sudo mount -a

The error message usually identifies an incorrect share name, filesystem type, option, or mount point.

The host folder is read-only

Check whether the share was added as read-only in the VM settings. Also check whether the host folder itself allows your host user to write to it.

Files are owned by root

This usually means the mount was performed by the root account without user-mapping options. Review the filesystem-specific permission options instead of applying an overly permissive recursive permission change.

Useful Verification Commands

# Show the mount configured for this directory
findmnt /mnt/shared

# Show filesystem type and available space
df -hT /mnt/shared

# Display the relevant fstab line
grep -n '/mnt/shared' /etc/fstab

# Show recent systemd mount messages
journalctl -b --no-pager | grep -i shared

Best Practices

  1. Always test with sudo mount -a before rebooting. A typo in /etc/fstab can cause boot problems.
  2. Use nofail for non-essential shares. The VM should still boot if the host share is unavailable.
  3. Use x-systemd.automount when the share does not need to be active immediately. It mounts when accessed.
  4. Keep a backup of /etc/fstab. The backup makes recovery easier if a configuration edit goes wrong.
  5. Avoid broad permission changes. Fix the host share or filesystem-specific mapping instead of using overly permissive settings.
  6. Use a dedicated host folder. Keeping shared files separate from private host files reduces accidental exposure.

Final Checklist

  • The host folder is configured in the VM settings
  • /mnt/shared exists inside Linux
  • A manual mount works
  • findmnt /mnt/shared shows an active mount
  • The correct entry is present in /etc/fstab
  • sudo mount -a completes without errors
  • The folder is available after a VM reboot
  • Your regular Linux user has the access level you need

With this setup, the host folder becomes available inside the Linux VM automatically whenever you restart it, while nofail helps keep the VM bootable if the host share is temporarily unavailable.