Changes to vdi image using vboximg-mount are not persistent

[crettien]

Scenario:

Code: Select all

vboximg-mount -i  <hdd uuid>--rw --root ./fuse_mount_point

Code: Select all

mount fuse_mount_point/vol3 /mnt

Code: Select all

touch /mnt/Users/admin/Documents/test-file.txt

Code: Select all

umount /mnt

Code: Select all

umount fuse_mount_point

So far so good, but the created file is not actually stored in the vdi image. Updating the vdi image is permitted while mounted with the described procedure but update is not persistent.

Host: Debian 4.19.98-1 (2020-01-26) x86_64
Guest: Win10 Pro 1909 French
VirtualBox: 6.1.2 r135662

There is a similar issue on Mac OSX host: viewtopic.php?f=8&t=96059

[jpt]

Hi,

So far so good, but the created file is not actually stored in the vdi image. Updating the vdi image is permitted while mounted with the described procedure but update is not persistent.

Host: Debian 4.19.98-1 (2020-01-26) x86_64
Guest: Win10 Pro 1909 French
VirtualBox: 6.1.2 r135662

similar problem here, two years later...

Code: Select all

vboximg-mount -i /30_MEG.vdi --rw -o allow_root /x
mount /x/vol0 /y
ls /y/
lost+found  remarque_bullseye.txt
touch /y/test-file.txt
ls /y/
lost+found  remarque_bullseye.txt  test-file.txt
sync
umount /y/
sync
umount /x/
sync
vboximg-mount -i /30_MEG.vdi --rw -o allow_root /x
mount /x/vol0 /y
ls /y/
lost+found  remarque_bullseye.txt

Host : Debian 5.10.84 Thu Mar 31 13:33:59 CEST 2022 x86_64 GNU/Linux
VirtualBox : 6.1.32 r149290 + GA.

[fth0]

Do you use snapshots? Did you check the output of VBoxManage showmediuminfo /30_MEG.vdi and vboximg-mount --list --wide?

Additionally, check if root is allowed to write to fuse mounted devices in your Linux host OS, which may be a configurable option.

[jpt]

Hi !
Thanks for your reply. Here are the answers :

Do you use snapshots?

No.

Did you check the output of VBoxManage showmediuminfo /30_MEG.vdi and vboximg-mount --list --wide?

Code: Select all

VBoxManage showmediuminfo /30_MEG.vdi
UUID:           312021c6-0344-4e76-8c30-3249eeb7deb2
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /30_MEG.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       30 MBytes
Size on disk:   9 MBytes
Encryption:     disabled
Property:       AllocationBlockSize=1048576

Code: Select all

vboximg-mount --list --wide

displays a list of the virtual machines available in my computer, with the attached disk(s), so I don't see /30_MEG.vdi which is a stand-alone copy of a file coming from an old test-machine.
From years I didn't get problems like that, using vdfuse in a 32bits context.

But that file is perfectly usable like that :

Code: Select all

vdfuse -f /30_MEG.vdi /x/
ls /x/
EntireDisk  Partition1
mount /x/Partition1 /y/
ls /y/
lost+found  remarque_bullseye.txt  sansloop.txt  testfile.txt

vdfuse is coming from vdfuse.c, modified et recompiled for 64 bits.

Additionally, check if root is allowed to write to fuse mounted devices in your Linux host OS, which may be a configurable option.

in /etc/fuse.conf ?
I have the line

Code: Select all

user_allow_other

and the comments above are not very clear for non-english native speaking people (like me).
EDIT : when I say "above", it's regarding the

Code: Select all

/etc/fuse.conf

file, of course. /EDIT

[fth0]

Ok, so it's a normal base VDI with standard settings. Perhaps vboximg-mount --list --image=/30_MEG.vdi --verbose --wide can give us more information. When the file system has been mounted, what does a simple mount command show as the mount's properties?

I'm also no native English speaker, and I have to admit that my statement possibly wasn't correct English. If you like, you can write in your native language, and Google Translate will try to help us.

[jpt]

Hello !

Ok, so it's a normal base VDI with standard settings.

Cool ! Fine ! Thanks !

Perhaps vboximg-mount --list --image=/30_MEG.vdi --verbose --wide can give us more information.

Caution with that still alive bug/typo in manual (and the web...) :
wrong

Code: Select all

vboximg-mount --list --image=/30_MEG.vdi --verbose --wide

good

Code: Select all

vboximg-mount --list --image /30_MEG.vdi --verbose --wide

notice the wrong "--image=", corrected with a space "--image " !
Do they check their products, in regard of their manuals ?

Well, and so :

Code: Select all

vboximg-mount --list --image /30_MEG.vdi --verbose --wide
[empty line]
Attempting to lock medium chain from leaf image to base image
  30_MEG.vdi ... Locking for read
[empty line]
Creating container for base image of format VDI
[empty line]
Opening medium chain
  Open: /30_MEG.vdi
[empty line]
Virtual disk image:
[empty line]
   Base: /30_MEG.vdi
   UUID: 312021c6-0344-4e76-8c30-3249eeb7deb2
[empty line]
Partition      Boot  Start  Sectors   Size  Offset  Type          
30_MEG.vdi(0)           17  61387    29.9M    8704  Linux native  
[empty line]

When the file system has been mounted, what does a simple mount command show as the mount's properties?

Code: Select all

vboximg-mount -i /30_MEG.vdi --rw -o allow_root /x
mount
...
vboximg-mount on /x type fuse.vboximg-mount (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

I'm also no native English speaker, and I have to admit that my statement possibly wasn't correct English.

No no, it's all perfect.

If you like, you can write in your native language, and Google Translate will try to help us.

Oh no, sometimes it's just incomprehensible,
I prefer continuing like that.

And, by the way, I'll be happy to read how Oracle's people work with vboximg-mount, regarding that problem...

Maybe the culprit is here, in the output of the your command :

Code: Select all

vboximg-mount --list --image /30_MEG.vdi --verbose --wide
Attempting to lock medium chain from leaf image to base image
  30_MEG.vdi ... Locking for read

EDIT Locking for read means not allowing writes, right ? /EDIT
So that's why I mount my file with the "--rw" flag, with no luck...

(sorry for the delay regarding my reply, I've checked "Notify me when a reply is posted" and received nothing...)

[fth0]

In the meantime, I tried a similar procedure myself and can confirm that it also didn't work for me. Clearing the Linux Page Cache (e.g. sync; echo 1 > /proc/sys/vm/drop_caches) during the test eliminates the written data from the file immediately. I'd suggest to create a ticket in the Bugtracker.

Regarding the "=" in the VirtualBox User Manual, it's supposed to work. Since it doesn't work, it's also a bug.

Regarding the "Locking for read", if you add the "--rw" option, you'll get "Locking for write" (even when using the "--list" option ).

[jpt]

Hello !

In the meantime, I tried a similar procedure myself and can confirm that it also didn't work for me. Clearing the Linux Page Cache (e.g. sync; echo 1 > /proc/sys/vm/drop_caches) during the test eliminates the written data from the file immediately. I'd suggest to create a ticket in the Bugtracker.

Done. See: https://www.virtualbox.org/ticket/20896

Regarding the "=" in the VirtualBox User Manual, it's supposed to work. Since it doesn't work, it's also a bug.

Also done : https://www.virtualbox.org/ticket/20897

Thanks for your help,
--
jp

[jpt]

Hi !

Done. See: https://www.virtualbox.org/ticket/20896

Things move !

Yes, known issue. Fixed after 6.1.34. We're working on getting test builds out which is a bit more tedious than usual (blasted code signing...).

[fth0]

I've successfully verified the bugfix with the VirtualBox test build 6.1.35r151427.

@jpt: Please check if it also works for you.

[jpt]

Helo !

@jpt: Please check if it also works for you.

It works !

Good job, folks. Thanks a lot and have a nice day.
Problem solved.

[fth0]

Thanks for reporting back!