VirtualBox

Ticket #17360 (closed defect: fixed)

Opened 22 months ago

Last modified 5 weeks ago

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

Description

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

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

Change History

Changed 22 months ago by thurask

VirtualBox log file

comment:1 Changed 22 months ago by thurask

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 22 months ago by thurask (previous) (diff)

comment:2 Changed 20 months ago by 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.

comment:3 Changed 19 months ago by thurask

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

comment:4 Changed 17 months ago by 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.

comment:5 Changed 17 months ago by thurask

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

Last edited 17 months ago by thurask (previous) (diff)

comment:6 Changed 17 months ago by CTGreybeard

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

comment:7 Changed 17 months ago by hlr

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

comment:8 Changed 17 months ago by thurask

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

comment:9 Changed 17 months ago by 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...

comment:10 Changed 15 months ago by 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 :-)

Last edited 15 months ago by AT-Fritz (previous) (diff)

comment:11 Changed 13 months ago by 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).

Last edited 13 months ago by Johannes (previous) (diff)

comment:12 Changed 12 months ago by 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?

comment:13 Changed 12 months ago by karlsson

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

comment:14 Changed 12 months ago by 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.

comment:15 Changed 9 months ago by 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.

comment:16 Changed 9 months ago by 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

comment:17 Changed 7 months ago by klaus

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 Changed 6 months ago by 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.

Last edited 6 months ago by bird (previous) (diff)

comment:19 Changed 5 months ago by michael

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from Cannot mount loop device from within shared folder on 5.2.x to Cannot mount loop device from within shared folder on 5.2.x -> fixed in 6.0.6

comment:20 Changed 5 weeks ago by 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).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use