How to get write access in guest os (linux) for raw disk (ext4) with virtualbox on Win7 host?

Question

I created the vmdk-file as describe in Chapter 9. Advanced topics and added it to my guest vm. After it, I could mount the entire raw disk up in my linux guest vm. Now I can read the ext4 file system, but I can't write to it. How can I get write access without changing the file system to NTFS? In Win7, I cannot set permissions to that hard disk because it's a raw hard disk with an unknown file system.

Solution 1

Okay, I found a solution by myself. Now, I want to give you detailed instructions about the steps I did to get it working.

My setup

VirtualBox 4.2.0 r80737
Host: Windows 7 (64-bit)
Guest: Ubuntu 12.04 LTS (64-bit)

Disk configuration in Win7 (host)

1. Close all open programs or documents on any partition on the disk to pass-through.
2. Run DISKPART (command line utility) as admin.
3. Type LIST DISK to get a list of all available disks and their related ids. (LIST PARTITIONS if you want to use just a part of the whole disk)
4. Select hard drive carefully using SELECT DISK.
5. Offline the disk using OFFLINE DISK. All disk volumes will disappear from windows explorer.
6. Type ATTRIBUTES DISK CLEAR READONLY (important!) to make sure the disk will be writable.
7. Verify with ATTRIBUTES DISK.

VMDK file creation in Win7 (host)

1. Run cmd (command line utility) as admin.
2. Type cd "C:\Program Files\Oracle\VirtualBox"
   (your path can differ dependent on your VirtualBox location).
3. Type VBoxManage internalcommands createrawvmdk -filename /path/RawDisk.vmdk -rawdisk \\.\PhysicalDrive1
   (PhysicalDrive1 means second drive)

(Source: VirtualBox Manual: Advanced storage configuration)

Add VMDK file to your Linux VM (guest)

1. Open VirtualBox Manager
2. Select Linux VM > Settings > Storage > IDE Controller > Add Attachment > Add Hard Disk > Choose existing disk > Select VMDK file
3. Start Linux VM

Set permissions and mount raw disk

If you use Ubuntu then you should already see the drive in the navigation pane of the file explorer. If you would click on it now, you would just mount the drive read-only to /media/drivename. To prevent this, open up a terminal and put the following into it:

cd /media
sudo mkdir DRIVENAME
sudo chown USERNAME DRIVENAME
sudo chgrp USERNAME DRIVENAME

(replace DRIVENAME and USERNAME with proper values)

Reopen the file explorer and mount the drive by clicking on its name in the navigation pane. Now you should be able to create files and folders on your raw hard disk.

Further information

Of course it is possible to permanently mount the disk via /etc/fstab, but then you have to sudo mount the device and the graphical mounting via navigation pane won't work anymore.

After the VMDK file creation I noticed the following line in there:

ddb.adapterType="ide"

This option is set by default. If you still run into issues and your raw disk is not an IDE disk but SATA, just change this line to:

ddb.adapterType="sata"

Of course then you have to add the VMDK file as SATA Controller to your VM instead of IDE Controller.

Solution 2

The disk will appear in your guest as /dev/sda1 (consult virtual box' docs). You need to mount that drive read-write. The easiest way to configure this permanently is by adding a line to /etc/fstab such as this:

/dev/sda1      /mnt/raw/disk-file/        ext4      defaults    0 2

If you wish to remount the drive read-write on the fly, you may issue the comamnd:

mount -o remount,rw /dev/sda1 

Again, this is assuming that the device for the drive is sda1. If you have nothing like that, then I would look trough the output of dmesg scanning for lines with "ATA" or "SCSI" as that will lead you to the device node of the drive. Usually It's really easy to spot in the /dev/ folder. Just look for hd[abcd..][1234] or sd[abcd..][1234...].

Comments

[StarNamer]

I found I needed to run VirtualBox with administrator access in order to fully access raw disks under Win 7. Have you tried that?

[Marc]

Sorry, doesn't work too.

[terdon]

How are you mounting the drive? Can you write to it as root from the linux guest?

[Marc]

Did it by clicking the hdd in the file browser to mount it. I also tried sudo mount /dev/sdb1/ /media/Data and it was mounted then, but without write permissions.

[kovica]

If you mount is and then run mount command then you should see something like: /dev/sdb1 on /media/Data type ext4 (rw,errors=remount-ro). rw means that the drive is in read-write mode. To remount it in rw mode you could try mount -o remount,rw /dev/sdb1

[Marc]

Doesn't do anything. I think it's not the guest os (linux), which causes the issue. I think it is the host (Win7), because I remember that I tried this before, but via VMware. At that time I had to change the file system from ext4 to ntfs. If the vm (guest) talks to Win7 (host) to let Win7 talk to the raw disk, then it is logical that it doesn't work. Win7 can't read/write to ext4. But is there no way to let the guest talk directly to the raw disk?

[Marc]

After adding the line into /etc/fstab the drive disappeared from file-explorer and the mount command just throw a "bad operation" error. I removed the line from /etc/fstab and the drive appeared in the file-explorer again, but when I click on it to mount the drive (read-only) the VM crashes now with a BLKCACHE_IOERR error ID.

[Ярослав Рахматуллин]

You don't have to run mount if you have it /etc/fstab. That's the whole point. The second argument i.e. `/mnt/raw/disk-file/' is an arbitrary path where you want the disk to "appear in file-explorer".

[Marc]

I know, but it didn't work via /etc/fstab or via mount. I still think it is not wrong mounting going on here, but rather no compatibility to access ext4 through a windows host.

[Ярослав Рахматуллин]

Windows writes to a "raw file" or a partition. It doesn't need to know ext4. The guest knows it's ext4, there is no need for windows ext4 "compatibility". look here: superuser.com/questions/407977/… He fixed his problem, and the issue was not the filesystem type. Anyway... gl

[Cauterite]

thanks; the one thing i hadn't tried was leaving the disk in the 'offline' state when booting the VM, which turned out to be the solution