shared folder problem! can see files but with wrong data!

[mad_waaah]

Hello, I installed a kali 2020.1 on VB Version 6.1.30 r148432 (Qt5.6.2), then linked the shared folder.
the problem on the quest OS is when reading something like a plain text file, the contents seem like they are damaged, i tested other files and i got the same thing, compared the hash on windows (host) and on linux (guest) and they were different.
but when i get those files some other way (other than through the shared folder on the guest side) like download from the internet or carry them on a USB, the data seems correct.
I'm on windows 10 version 21H1 (OS Build 19043.1526).
this seem like a bug o me.

[scottgus1]

We need some kind of solid evidence of what you're seeing. It does not sound familiar to me.

[mpack]

Provide a VM log file. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

[mad_waaah]

here i saved a log file after i recreated the issue with a text file.
one other thing to note is after installing kali-linux-2022.1-i386 and created the shared folder i still couldn't access it(permission denied), this command did the trick "sudo adduser $USER vboxsf" + restart.

[mad_waaah]

We need some kind of solid evidence of what you're seeing. It does not sound familiar to me.

hello, so you are saying this is something happening only to me?! did you actually try?

[mpack]

hello, so you are saying this is something happening only to me?

I've never heard anyone else report it. We use shared folders all the time, I think we would notice if files were corrupted en route to the VM. My suspicions are therefore that your problem is peculiar to you and your system, perhaps a side effect of nasty third party AV.

[scottgus1]

Same as Mpack's thoughts for me. This isn't happening forum-wide. And believe me we would have heard about it.

Most of the time the one-off problems reported by a single user end up being caused by other software on the user's host.

[mad_waaah]

so, i installed kali-linux-2021.2-virtualbox-amd64 and the shared folder worked there! the differences between the two are:

i386 -> amd64
installed from iso -> pre installed (.ova file)
installed without swap partition -> not sure if it have a swap partition
installed on C: (SSD) -> installed on D: (HDD)

i'm goin to try another OS!

[mad_waaah]

so, i installed debian i386 and debian amd64 guest systems, and again the i386 show damaged like files and amd64 correctly shows files data! can somebody tell my why?

[scottgus1]

So far, no. We need evidence that it's happening, please. A screenshot, a VM log, etc.

[sudharsun]

same problem for me in debian i386 and kali linux i386. when checked the files in the shared folder with "file" command it says "data" for all files(txt, pdf, zip, tar, gz ...).
I checked in Window 10 host debian/kali i386 guest and Ubuntu 20.04 host debian/kali i386 guest.

debian/kali linux amd64 machines are fine.

[scottgus1]

same problem for me

We need evidence that it's happening, please. A screenshot, a VM log, etc.

[mpack]

Thinking about it, this makes little sense.

A shared folder is not hardware, it's a data transfer protocol, i.e. like a file download. So if, let's say, the wrong part of the host drive is being read due to some kind of directory indexing error, then the fault would be on the host OS, not in VirtualBox. So run a filesystem check on the host.

Since this involves the Guest Additions it is admittedly possible that VirtualBox is corrupting data in whatever equivalent of data packets that the GAs uses during bulk transfers. Possible, but IMO rather unlikely: if this were systemic then I'd expect more than two reports ever. And why does it only affect some versions of Linux guests? Why both reports came this year? I'd like to see a VM log from one of these guests, showing that the GAs code is official, and not a third party build.

[VM user]

Same problem here. VirtualBox 6.1, Fedora 30 on Windows 10 host.

Create on Fedora:

shared1.jpg (17.17 KiB) Viewed 3255 times

Read on Windows:

shared2.jpg (27.17 KiB) Viewed 3255 times

It appears that the file gets corrupted as it is written to the shared folder on the Fedora side. Creating on the Windows side is slightly different in that the file is OK on the Windows side.

Create on Windows:

shared3.jpg (30.67 KiB) Viewed 3255 times

Read on Fedora:
(cannot add the 4th picture - maximum 3 per post. but the data is garbage)

Curiously dos2unix and unix2dos bail out with the error message:
Binary symbol 0x0E found at line 1
Skipping binary file test.txt

I also tried other types of files:
jpg --> picture viewer failed with "It appears that we don't support this file format"
tgz --> 7zip failed to open archive

[scottgus1]

Good! Solid data at last!

VM User, could you please do the same "Hello world!" test from both host and VM, then open the files from the other OS with a hex editor, so we can see what the other OS sees.

Also, please post a VM log:
Start the VM from full normal shutdown, not save-state. Try the experiment above, then shut down the VM from within the VM's OS if possible. If not possible, close the Virtualbox window for the VM with the Power Off option set.

Right-click the VM in the main Virtualbox window's VM list, choose Show Log. Save the far left tab's log, zip it, and post the zip file, using the forum's Upload Attachment tab.