Cannot mount loop device from within shared folder on 5.2.x -> fixed in 6.0.6

[thurask]

Host: Windows 10 Enterprise v1709 AMD64

Guest: Xubuntu 17.10 AMD64

On 5.2.2 r119230 and 5.2.3 r119552, attempting to mount an EXT4 partition image on the Linux guest stored in a shared folder on the Windows host fails with "mount: can't read superblock on /dev/loop0". 5.1.30 did not have this issue as far as I can remember.

With a new and up-to-date Xubuntu VM and Guest Additions installed:

$ cd /media/sf_SharedFolder
$ dd if=/dev/zero of=test.img bs=4k count=60000
$ sudo mkfs.ext4 test.img
$ mkdir testout
$ sudo mount -o loop test.img testout/
"mount: /media/sf_SharedFolder/testout: can't read superblock on /dev/loop0"

Doing the same thing on a folder inside the VM storage (like ~) correctly mounts the EXT4 image. The shared folder can be read from and written from within the VM as long as there's no loop mounting.

[thurask]

VirtualBox log file

[thurask]

Downgrading to 5.1.30 r118389 + corresponding Guest Additions restores mounting from within a shared folder.

[Fatalblow]

Host: Windows 10 Education Version 1607 (OS Build 14393.1480)

Windows 10 Professional latest build and updates.

Guest: Xubuntu 17.10 AMD64

Mint 18.1 xfce AMD64 Mint 18.3 xfce AMD64

I'm observing similar behavior.

When attempting to mount the second partition from a .img file I see the following.

sudo mount -o loop,offset=63963136 test.img /mnt/part1 mount: /dev/loop0: can't read superblock

This works fine up to version 5.2.0-118431 + Guest Additions 5.2.1 for me. 5.2.2/4/6 all show the same fault.

[thurask]

Still present on 5.2.8 r121009 with the same host and guest.

[thurask]

After updating to Xubuntu 18.04 LTS, the bug is now present even on 5.1. Upgrading to 5.1.36 r122416 and Windows 10 Enterprise v1803 did not reintroduce the bug prior to upgrading Xubuntu.

The issue is still present on 5.2.10 r122406 as well.

[thurask]

5.2.10 r122406 also has the same issue with a Fedora 27 guest.

[Bill Waggoner]

5.2.10 on a Mac (10.13.4) with Ubuntu 18.04 Server as guest gives the error also.

[hlr]

5.2.10 r122406 on a Windows 10 x64 host and Ubuntu 18.04 Desktop guest also gives this error.

[thurask]

Still present on 5.2.10 r122591 with the same Windows 10 1803 host and Xubuntu 18.04 guest.

[Socratis]

I don't know who I was talking over at IRC, but I'll repeat here.

VirtualBox's Shared Folders present a very simplified file system implementation, just enough to read/write files from/to the guest. Many applications can error when using Shared Folders, because they expect advanced features, for example file locking, access controls, etc., which don't exist as a concept for Shared Folders.

See if you can get it to work with true network shares...

[AT-Fritz]

Same issue with Guest OL7.5 on VBox 5.2.12 and GuestAdditions 5.2.12.

From a shared folder:
[root@OL7 OVM_3.4.x]# mount -o loop ovmm-3.4.5-installer-OracleLinux-b1919.iso /mnt
mount: /dev/loop0: can't read superblock

From a local folder:
[root@OL7 ovm]# mount -o loop ovmm-3.4.5-installer-OracleLinux-b1919.iso /mnt
mount: /dev/loop0 is write-protected, mounting read-only

Crazy stuff :-)

[Johannes]

Same issue still present on 5.2.18.

Kinda nuts that this is still a bug; especially since this used to work for 5.1.x (seems to be fine on latest version 5.1.38).

[dho]

I downgraded to 5.1.38, and noticed that the problem did not go away until I removed the 5.2 guest additions and installed the guest additions for 5.1.38. So it seems that the problem might be associated with the 5.2 Linux guest additions, and not virtualbox itself. Has anybody tried upgrading virtualbox from version 5.1 to 5.2 without upgrading the guest additions?

[karlsson]

Problem is somwhere in VBoxGuestAdditions disk. No need downgrade host. ​https://forums.virtualbox.org/viewtopic.php?f=3&t=86050&p=429494

[Donuts]

I'm also seeing this issue. Host Windows 10 1803, guest Lubuntu 18.04. Can't mount image file if it's on host shared folder, but copy to guest HD and mounting works fine.

Worth noting, running md5sum on the in-host-shared-folder image file gives the correct result, so there must be some incompatibility of Linux guest additions with the file I/O access pattern when you attempt to mount an image file.

[Willard Dawson]

I have this issue as well. Host: Windows 7 Pro. Guest: Gentoo (Pentoo). Vbox 6.0.0 with corresponding guest additions. I thought this was a Linux kernel version related issue until I found this page.

[mira-evan]

I have this issue as well. Example:

$ sudo kpartx -v -l -a /media/sf_vshare/MR.img
/media/sf_vshare/MR.img: Operation not permitted
can't set up loop

Host: macOS 10.12.6 (Build: 16G29)
Guest: Ubuntu 18.04 Desktop 64-bit
VirtualBox: Version 6.0.0 r127566 (Qt5.6.3), guest additions matched

[Klaus Espenlaub]

From a first peek this could be a regression caused by the fixing of #819 and #17053, since this was the major change between 5.2.0 and 5.2.2 as far as shared folder functionality is concerned.

[bird]

Trouble seems to be missing file_operations::read_iter() and file_operators::write_iter() implementations. These operations were introduced in linux-3.16, though I haven't checked exactly when the loop back block device started using them. Working on a fix now, hoping to get it into one of the next 6.0.x releases.

[oracleaccount34]

VirtualBox 6.0.6 actually broke certain parts of shared folders. I stumbled upon it due to this bug: ​https://github.com/Ocramius/PackageVersions/issues/107, but after some digging it turns out that downgrading to 6.0.4 fixed the issue (I tried all newer versions up to and including 6.0.10).