To the Home Page

Moving development to a virtual machine

Published on February 7, 2026 · Reading time: 4 minutes

With the widespread adoption of vibe-coded software of dubious quality, various security issues and numerous supply chain attacks, apparently bad design of both Python and Node.js package managers (packages can run arbitrary scripts during installation), current geopolitical issues and their side effects, and, finally, lack of enforced sandboxing on Windows, Linux, and macOS in 2026, some questions resurface. Should I really run any third-party software on my main OS? Isn’t it safer to do any development in a virtual machine? What about Docker containers running as root, browser plugins, GNOME Shell extensions, third-party text editor themes?

But first, let’s focus on the main problem: how to efficiently share files from the main (host) OS to a VirtualBox guest, both Linux?

Table of Contents

Shared folders

This feature is available in the VM settings. Make sure you have Guest Additions installed and your guest user is in the vboxsf group (requires reboot):

sudo usermod -aG vboxsf GUEST_USERNAME

It works fine for simple projects without Git.

It works okay if you have Git configured to ignore permission differences of non-committed files. Obviously, you will need to push and pull changes using the host OS, because the guest OS doesn’t have access to any SSH keys.

git config core.filemode false

It all falls apart if you need advanced filesystem features like permissions or symlinks. Node.js projects usually don’t work because of the symlinks in node_modules directory. With Python, you can have a virtualenv literally anywhere. Not sure about other programming languages.

Using VirtualBox Shared Folders (guest)
Using VirtualBox Shared Folders (guest)

Shared disk image

This is very similar to what Microsoft does with WSL2 or Dev Drive. You can’t mount the image on both the host and guest OS at the same time, but you get a near-native performance.

First, open the VirtualBox global settings and create a new VDI disk image. Do not store it in the VirtualBox VMs directory. Attach this image to the existing VM as a second disk.

Setting up second virtual disk (host)
Setting up second virtual disk (host)

Install GParted on the guest OS and create a new EXT4 partition. Create a working directory that can be accessed by a non-root user:

sudo mkdir data
sudo chown -Rv GUEST_USERNAME:GUEST_USERNAME data

Hint: make sure both host and guest users have the same ID. By default, it’s 1000 for the first user.

$ id -u
1000

If you want to mount the image on the host OS later on, install the qemu-utils package and run the following commands:

sudo modprobe nbd
sudo qemu-nbd --connect=/dev/nbd0 current.vdi
sudo qemu-nbd --disconnect /dev/nbd0

Using virtual disk image (host)
Using virtual disk image (host)

Network share

There are some workarounds if you really need to access the virtual drive’s contents while the VM is running. For example, you can set up a network share.

You need to create a new “host-only network” in the global VirtualBox settings, with a predictable IP of 192.168.56.1. If your VM needs internet access, you have to configure its first network adapter as “NAT”, and the second one as the newly created “host-only” adapter.

Setting up a virtual network (host)
Setting up a virtual network (host)

You may also have to remove the default NetworkManager profile and create two separate ones, or NetworkManager would be unable to keep both networks enabled simultaneously.

nmcli connection delete "Wired connection 1"
nmcli connection add type ethernet ifname enp0s3 con-name "NAT"
nmcli connection add type ethernet ifname enp0s8 con-name "Host-only"

Then you need to install an NFS server on the guest OS (nfs-kernel-server package) and configure a /etc/exports file to allow access to selected directories:

# Add this line
/media/test/SHARED/data  192.168.56.1(rw,sync)

Reload the configuration file with this command:

sudo exportfs -ra

You also need an NFS client on the host OS (nfs-common package). Create a temporary directory and mount the “remote” resource there:

mkdir -p current-nfs
sudo mount -t nfs 192.168.56.101:/media/test/SHARED/data current-nfs

You can now open a terminal window and run git push, without having to store SSH keys in a virtual machine.

Using NFS network share (host)
Using NFS network share (host)

Check out other blog posts: