A field guide on passing an existing 18TB physical ext4 partition from a Windows 10 host to an Ubuntu VM without losing data.
I recently migrated an 18TB HDD filled with media files from a retired Linux server to my main Windows 10 workstation. The disk was formatted in ext4, which Windows cannot read natively without third-party tools (which are often unstable).
Instead of formatting the drive or fighting with WSL2 mounting quirks, I decided to pass the physical partition directly into a VMware Workstation Ubuntu guest.
These are my notes on the process, the pitfalls (permissions!), and the configuration required to make it stable.
The Concept: Partition Passthrough
VMware allows “Raw Device Mapping” (RDM) in two ways:
- Use entire disk: The VM takes total control.
- Use individual partitions: The VM only sees specific partitions. (Recommended)
I chose the individual partition method.
Crucial Distinction: When you use this method, VMware creates a small virtual disk file (.vmdk) that acts as a proxy.
- To the Guest OS (Ubuntu), this looks like a new hard drive (e.g., /dev/sdb).
- The actual physical data sits on the first partition of that virtual drive (e.g., /dev/sdb1).
- Rule: You mount the partition (/dev/sdb1), not the raw device (/dev/sdb).
Prerequisite: Host Preparation (Windows)
Before touching VMware, the physical disk must be prepped in Windows.
- Open Disk Management (diskmgmt.msc).
- Locate the target Linux disk.
- Ensure the disk status is Online. If it says “Offline,” right-click and select “Online”.
- WARNING: Windows will likely pop up a dialog saying “The disk you inserted was not readable by this computer” and ask you to format it. CLICK CANCEL. Do not assign a drive letter.
Step 1: VMware Configuration
The “Insufficient Permission” Trap: If you try to add a physical disk while running VMware as a standard user, you will likely see this error later:
Failed to load partitions for device \.\PhysicalDriveX: Insufficient Permission to access file.
Fix: Always launch VMware Workstation as Administrator.
Configuration Steps:
- Go to VM Settings > Hardware > Add…
- Select Hard Disk > SATA (SATA is usually best for physical HDD passthrough compatibility).
- Select Use a physical disk (for advanced users).
- Device: Select the correct PhysicalDriveX (Match the number from Windows Disk Management).
- Usage: Select Use individual partitions.
- Select Partitions: Check the box for your Linux data partition (e.g., Partition 1, Linux FS, 16.4TB).
VMware will ask to save a .vmdk file. Store this alongside your other VM files.
Step 2: Guest Mounting (Ubuntu)
Boot up the Ubuntu VM.
1. Identify the Device
Use lsblk to find the new disk. It will likely be the last device listed.
lsblk
Output example:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 1M 0 part
└─sda2 8:2 0 50G 0 part /
sdb 8:16 0 16.4T 0 disk
└─sdb1 8:17 0 16.4T 0 part
Here, sdb is the virtual container, and sdb1 is my actual 18TB physical partition.
2. Manual Mount Test
Create a mount point and try to mount it manually first.
sudo mkdir -p /mnt/media
# Remember: Mount the partition (sdb1), NOT the disk (sdb)
sudo mount /dev/sdb1 /mnt/media
If successful, verify you can see your files: ls -l /mnt/media.
Step 3: Permissions & Persistence
Simply mounting it isn’t enough. You likely need to fix ownership and ensure it remounts on reboot.
Fix Ownership (The 1000:1000 Issue)
ext4 preserves the numeric User ID (UID) from the old server.
- If your old user had UID 1000 and your new VM user is UID 1000, it works instantly.
- If they differ, or if the drive was owned by root, you won’t be able to write to it.
To change ownership to the current user:
sudo chown -R $USER:$USER /mnt/media
Auto-mount via fstab
Do not rely on /dev/sdb1 remaining constant (device names can shift). Use the UUID.
- Get the UUID:
sudo blkid /dev/sdb1
Copy the string looking like UUID=“5b32-xxxx-…”
- Edit fstab:
sudo nano /etc/fstab
- Add the line:
UUID=5b32-xxxx-yyyy-zzzz /mnt/media ext4 defaults,nofail 0 2
Note on nofail: This flag is critical for physical passthrough. If the external drive is disconnected or the VMware link fails, nofail allows the Ubuntu VM to boot anyway. Without it, the VM will hang in emergency mode.
Appendix: Errors & Warnings
“Cannot call Open vSwitch”
You might see this warning in the logs:
WARNING: root: Cannot call Open vSwitch…
Verdict: Ignore it. This is a benign Netplan warning checking for available network backends. If your network works, this is noise.
Disk “Busy” or locked on Windows
Ensure no other software on Windows (like ext2fsd or WSL) is trying to access the physical disk index while the VM is running. Accessing the raw disk from both Host and Guest simultaneously causes data corruption.