This post documents the one and only correct procedure for successfully passing through a physical ext4-formatted hard drive (e.g., an 18TB data disk) from a Windows 10 host to an Ubuntu VM in VMware Workstation. If you’re tired of failed attempts using “Offline” or “Use entire disk” methods, this guide is for you.

🚀 Why Do This?

When developing on Windows 10 (especially for DevOps or AI), we often use Linux VMs (like Ubuntu) to run services like Docker or Kubernetes. If our massive datasets (models, service data, etc.) are stored on a Linux-native ext4 drive, Windows can’t read it by default.
The cleanest, most efficient solution is to “pass through” this physical drive directly to the VMware VM and let Ubuntu manage it natively.

📋 Prerequisites

  1. Windows 10 Host: With VMware Workstation Pro installed.
  2. Ubuntu VM: Already installed (e.g., Ubuntu 22.04).
  3. ext4 Physical Drive: Connected to the Windows host.
  4. CRITICAL!: You must have Administrator privileges on Windows.

💡 Step 1: Defeat the “Achilles’ Heel” (Critical!)

Before you do anything else, you must solve the one error you will definitely encounter: Insufficient Permission to access file.
The Cause: VMware needs low-level, raw hardware access to see and manage physical disk partitions. Your standard user account does not have this permission.
✅ The Solution:
Always run VMware Workstation as an Administrator!

  1. Completely close VMware Workstation.
  2. Right-click the VMware icon.
  3. Select “Run as administrator”.

If you skip this step, nothing else will work.

Step 2: Configure the Windows Host (Set to Online)

You may have seen other tutorials that tell you to set the disk to “Offline”. For our “Use individual partitions” method, this is incorrect.

  1. In the Windows search bar, type “Disk Management” or run diskmgmt.msc.
  2. Find your ext4 drive (e.g., “Disk 1”, 16.4TB).
  3. Ensure its status is Online. If it’s “Offline”, right-click the disk (on the “Disk 1” label to the left) and select “Online”.

Windows will show the partition as “Healthy (Primary Partition)” but with no drive letter or recognized file system. This is normal.

⚙️ Step 3: Configure VMware VM Settings (The One True Path)

This is the core of the configuration. Follow this exact click path:

  1. In VMware (running as admin), select your Ubuntu VM and click “Edit virtual machine settings”.
  2. Go to the Hardware tab.
  3. Click Add… -> Hard Disk -> Next.
  4. For “Virtual disk type”, select SATA (best compatibility) -> Next.
  5. For “Select a Disk”, choose Use a physical disk (for advanced users) -> Next.
  6. For “Select a Physical Disk”:
    • Device: Select your ext4 drive. This must correspond to the number in Disk Management (e.g., Disk 1 = PhysicalDrive1).
    • Usage: You MUST select Use individual partitions! -> Next.
  7. For “Select Partitions”, VMware will read the drive’s partition table.
    • Check the box for your Linux partition (e.g., Partition 1 (Linux FS, 16.4TB)).
    • The fact that you can see Linux FS and the correct capacity proves you’ve done everything right so far.
  8. Click Next, then Finish. Save the settings.

🐧 Step 4: Mount and Verify in Ubuntu (The Final Step)

Now, boot your Ubuntu VM.
Important! You might think you’re passing in /dev/sdb1. You’re not! VMware virtualizes this partition as a new virtual disk, and that partition is the first partition on that new disk.

  1. Find the Device: Open a terminal and run lsblk. You will see output similar to this:
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT  
sda      8:0    0  16.4T  0 disk  <-- This is the new virtual disk  
└─sda1   8:1    0  16.4T  0 part  <-- This is the partition to mount\!  
sdb      8:16   0    50G  0 disk  <-- This is your Ubuntu system disk  
├─sdb1   8:17   0     1G  0 part /boot/efi  
└─sdb2   8:18   0    49G  0 part /

(Note: Your system disk and new drive might be sda or sdb. Use the SIZE (16.4T) to identify the correct one.)

  1. Create Mount Point (if needed):
sudo mkdir -p /mnt/data
  1. Execute Mount (Mount the sub-partition!): Based on the lsblk output, we are mounting sda1 (or sdb1, etc.).
# Assuming your 16.4T drive was identified as sda  
sudo mount /dev/sda1 /mnt/data

Do NOT try to mount /dev/sda. This is wrong and will fail.

  1. Verify:
df -h

If you see a line showing Filesystem /dev/sda1 and Mounted on /mnt/data, congratulations! You are done!

💡 Appendix: Other “Gotchas”

  • netplan apply Warning:
    If you see WARNING: root: Cannot call Open vSwitch: ovsdb-server.service is not running. when configuring a static IP:
    • This is a benign warning. netplan checks for all backends it can manage (including OVS). Since you don’t have OVS, it reports this. As long as your network is working, ignore it.
  • fstab Auto-Mounting:
    You can try to use the partition’s UUID in /etc/fstab for auto-mounting. However, the VMware physical disk passthrough can sometimes load slowly, which may cause your VM to fail on boot.
    • The Safer Method: Either accept “I will manually mount after each reboot” or put the mount command in your .bashrc or a startup script.

Hopefully, this detailed guide saves you hours of frustration and gets you back to focusing on your Docker services and data! 🎉