Shared folders between 64 bit host and 32 bit guests corrupt data.

[KimonHoffmann]

Writing to files shared via VirtualBox shared folders between a 64 bit host and a 32 bit linux guest leads to corrupted file contents on the opposing side.

This appears to be an issue between the upstream vboxsf module and the 64 bit host implementation, and I have been able to reproduce this issue without fail with multiple distributions if this condition was met.

Creating a file on the host side and viewing it on the guest side, yields:

• A file with the correct size
• Completely garbage content (apparently comprised of random guest memory).

Please note that this also applies to files that were already present, when the folder was first mounted in the VM.

Creating a file on the guest side and viewing it on the host side, yields:

• A file with the correct size
• Completely garbage content (probably also random memory).

Please note that when creating and later viewing a file on the guest side, its contents only appear unscathed for as long as the file stays in the cache. After executing a sync and dropping caches, its contents are just as garbled as if the file had been created on the host side.

This issue has been observed:

• on macOS as well as Windows host (we were not able to test Linux hosts yet).
• on VirtualBox versions going as far back as at least 6.1.28.

Neither the VirtualBox nor the vboxsf kernel module report any problems in either case.

--

People at Mageia have encountered what is probably the same issue and you can find the report including more elaborate analysis into what's happening here: ​https://bugs.mageia.org/show_bug.cgi?id=26214

I have discussed this problem in more detail in the context of a VirtualBox forum post that describes a similar issue, here: ​https://forums.virtualbox.org/viewtopic.php?f=6&t=105367&start=15#p523118

[galitsyn]

Hi KimonHoffmann,

There was a fix in this area in 6.1.40 (should also be a part of 7.0.4). You might want to update Guest Additions to either of these versions.

[KimonHoffmann]

Great to hear!

I'll upgrade the guest additions and report back.

[KimonHoffmann]

So I just retested this issue, after ensuring that all components are updated to version 6.1.40.

Unfortunately the issue persists as described. I was a bit skeptical of the update fixing the issue, since it happens with the upstream vboxsf module, and the interaction between the guest additions and the upstream driver are minimal to non-existent, but I wanted to give it a fair shot regardless.

[galitsyn]

Hi KimonHoffmann,

Note that upstream vboxsf module and the one which comes with Additions installer are technically speaking two different drivers. Could you please attach VBox.log and guest's dmesg output for 6.1.40?

[KimonHoffmann]

dmesg output 32 bit of linux guest.

[KimonHoffmann]

Vbox.log of session running 32 bit linux guest.

[KimonHoffmann]

Yes, I'm aware and the problem is specifically only happening with the upstream driver.

BTW: One of the distributions I've tested this with is a custom Linux distribution that we have available as a 32 Bit as well as a 64 Bit build that are identical (except for the necessary differences implied by varying architecture) where its immediately obvious that only the 32 Bit version suffers from this issue.

I attached the requested log files. The mount tag of the shared folder I was testing with was sf_test.

[galitsyn]

Hi KimonHoffmann,

Thank you for the logs. However, upstream version of vboxsf is maintained by other person (not by us). You might want to file a bug to kernel bugzilla.

Closing as invalid.