Best of Both Worlds: Running a Shared Lightroom Catalog across Linux and Windows

Adobe Lightroom Classic runs fine in a Virtual Machine (VM) on Linux for basic culling and editing. But heavy, GPU-based tasks like AI Denoise take a long time, because they have to run fully on the CPU instead. On my Intel Core i7 Gen 13 under Windows with a GeForce RTX 4070 Ti Super, de-noising a Nikon NEF with 45.7MP takes about 6s, in the VM it takes 15min—or about 150 times longer! Also having the catalogue and the images isolated inside the VM is not very practical.

Previously, I used to run the Lightroom catalogue and the images on a shared network drive together with the subst command, but that hack no longer works. It was a shaky setup from the beginning and also suffers from slow I/O performance, especially considering, that Lightroom constantly reads and writes to the catalog SQLite database as well as creates and loads previews from the cache.

A better solution is to run the Lightroom catalogue and the cache directly live from a virtual disk image (.vdi). The disk can then directly be attached as a native storage device to the VM, and crucially, also mounted as a physical disk in Windows using the specialized AIM toolkit.

Here is how to build this robust, hybrid workflow where you can use Linux for daily tasks and quickly fire up a Lightroom VM for culling and basic photo editing. When necessary, shutdown and boot into Windows for heavy, AI-driven tasks like Denoise. Use Duplicati for backups of the catalogue and the photos.

The Architecture of the Setup

To make this cross-OS workflow viable everything revolves around a single, shared NTFS partition. Both, Linux and Windows can read and write to this drive seamlessly:

  • The Photos (RAW files): They live in any folder structure of your liking on the NTFS drive and are directly available in Linux and Windows. Additionally, this drive is passed through to the VirtualBox VM as a Shared Folder on Linux,
  • The Catalog & Cache: The .lrcat database and the .lrdata preview folders live entirely inside the .vdi disk container. This .vdi file is simply stored on the NTFS drive right alongside the photo folders.

This architecture has several further advantages:

  • Backup Flexibility: Because the .vdi and the RAWs are both on a shared drive, you can technically run your backups from either OS. Keeping the photos outside of the .vdi keeps the virtual disk relatively small and fast.
  • No Vendor Lock-in: The .vdi can also be mounted by QEMU, so you don’t really need to use VirtualBox, especially when planning on implementing GPU passthrough. Furthermore, because the RAW files are sitting natively on a standard drive rather than being trapped inside a virtual disk container, they remain universally accessible by Linux-native software such as Darktable or digiKam without ever needing to boot up a VM or mount a virtual drive.
  • No Cross-OS Driver Headaches: Keeping the .vdi file itself on an NTFS partition means Windows can see the file natively without requiring unstable third-party Linux file system drivers.

Step 1: Create the VDI

Note: When I first built this setup, I created a .vhdx drive in Windows Disk Management and moved the catalogue and the caches into it, only to discover later that VirtualBox handles that format poorly, forcing me to converting it into a .vdi file via terminal on Linux. Save yourself the headache and directly create a native .vdi first on Linux.

Create the VDI Container in Linux: Open a terminal and use VBoxManage to generate a dynamically allocated .vdi. I allocated 250 GB to give my Lightroom catalogue and caches plenty of headroom.

$ VBoxManage createmedium disk --filename /media/simon/IMAGES/LR-Catalog.vdi --size 250000 --format VDI

Step 2. Format the VDI

1. Open VirtualBox and go to your Windows VM settings -> Storage, and attach the new LR-Catalog.vdi as a SATA hard disk.

2. Boot the VM and open Windows Disk Management. It will prompt you to initialize the disk. Create a New Simple Volume, format it as NTFS, and assign it a persistent drive letter (I used L: for Lightroom).

3. Shut down the VM. Do not copy your catalog and preview folders through the VirtualBox shared folder interface—the I/O overhead for thousands of files is going to be painfully slow.

Screenshot of the VirtualBox settings window showing the attached Virtual Disk Drive (VDI).
Screenshot of the VirtualBox settings window showing the attached Virtual Disk Drive (VDI) on Linux Mint.

Step 3. Move the Catalogue

To move your catalogue and caches at full hardware speed, bypass the VM entirely:

1. Reboot your computer into your native Windows installation.

2. Install AIM Toolkit: Download and install the free AIM Toolkit from SourceForge. This tool enables Windows to mount VirtualBox .vdi files as physical SCSI drives using the included Arsenal Image Mounter driver.

3. Open the Mount Image File application from your Windows Start Menu and select your LR-Catalog.vdi file. In the mount options, ensure that Windows assigns it the exact same drive letter (L:) that you used inside the VirtualBox VM.

4. Move the whole Lightroom folder containing the catalogue .lrcat, previews and helper data .lrdata from their old location onto the newly mounted L: drive using Windows Explorer. Double-click the .lrcat file in its new home to test-launch Lightroom.

Screenshot of the AIM Toolkit setup and Windows Explorer showing the mounted Virtual Disk Drive (VDI).
Screenshot of the AIM Toolkit setup and Windows Explorer in the back showing the mounted Virtual Disk Drive (VDI) on Windows 11.

Step 4: Backup the VDI

Shutdown and boot into Linux to setup the Duplicati backup of the catalogue and the photos by pointing it to the the single LR-Catalog.vdi file and to the folder containing the images. Because Duplicati relies on block-level deduplication, it doesn’t upload the entire 250 GB file. It scans the .vdi, identifies the specific data blocks that changed that day, and only backs up the delta. It is fast, secure, and natively handled by Linux without ever needing to boot up the Windows environment.

Note: Workflow and architecture by me; drafting, typing and formatting assisted by Google Gemini.

Leave a comment

Your email address will not be published. Required fields are marked *