Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#17360 closed defect (fixed)

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

Reported by: thurask Owned by:
Component: shared folders Version: VirtualBox 5.2.0
Keywords: shared, folder Cc:
Guest type: Linux Host type: Windows


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.

Attachments (1)

Xubuntu 17.10-2017-12-08-17-04-35.log (194.3 KB ) - added by thurask 6 years ago.
VirtualBox log file

Download all attachments as: .zip

Change History (21)

by thurask, 6 years ago

VirtualBox log file

comment:1 by thurask, 6 years ago

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

Edit: 5.1.31 r119333 + Guest Additions 5.1.31 r119566 works as well.

Last edited 6 years ago by thurask (previous) (diff)

comment:2 by Fatalblow, 6 years ago

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.

comment:3 by thurask, 6 years ago

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

comment:4 by thurask, 6 years ago

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.

comment:5 by thurask, 6 years ago

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

Last edited 6 years ago by thurask (previous) (diff)

comment:6 by Bill Waggoner, 6 years ago

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

comment:7 by hlr, 6 years ago

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

comment:8 by thurask, 6 years ago

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

comment:9 by Socratis, 6 years ago

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...

comment:10 by AT-Fritz, 6 years ago

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 :-)

Last edited 6 years ago by AT-Fritz (previous) (diff)

comment:11 by Johannes, 6 years ago

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).

Last edited 6 years ago by Johannes (previous) (diff)

comment:12 by dho, 5 years ago

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?

comment:13 by karlsson, 5 years ago

Problem is somwhere in VBoxGuestAdditions disk. No need downgrade host.

comment:14 by Donuts, 5 years ago

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.

comment:15 by Willard Dawson, 5 years ago

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.

comment:16 by mira-evan, 5 years ago

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

comment:17 by Klaus Espenlaub, 5 years ago

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.

comment:18 by bird, 5 years ago

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.

Last edited 5 years ago by bird (previous) (diff)

comment:19 by Michael Thayer, 5 years ago

Resolution: fixed
Status: newclosed
Summary: Cannot mount loop device from within shared folder on 5.2.xCannot mount loop device from within shared folder on 5.2.x -> fixed in 6.0.6

comment:20 by oracleaccount34, 5 years ago

VirtualBox 6.0.6 actually broke certain parts of shared folders. I stumbled upon it due to this bug:, 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).

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use