Bug 106701

Summary:	Virtualbox shared folder module problem on latest kernel
Product:	Other	Reporter:	Tom B (tom)
Component:	Modules	Assignee:	other_modules
Status:	NEW ---
Severity:	normal
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.2	Subsystem:
Regression:	No	Bisected commit-id:

Description Tom B 2015-10-27 11:58:53 UTC

I'm not sure if this is a kernel issue or a Virtualbox issue so apologies in advance if it's not. However, I can only replicate it on newer Kernels.

So far I've tried Kernel versions: 4.2, 4.1 and 3.17. 4.1 and 4.2 are affected, whereas it works as expected on 3.17.

Steps to reproduce:

Create a Linux guest inside Virtualbox, then:

1) GUEST: mount a shared directory: mount -t vboxsf share_name /media/share

2) GUEST: cat /media/share/existing.file <-- Works perfectly, displays the contents of the file from HOST

3) HOST: Write new.file into the shared folder:

4) GUEST: cat /media/share/new.file <-- Works perfectly, displays contents of newly created file

5) GUEST: stat /media/share/non-existing.file <-- As expected displays "no such file or directory"

6) HOST: Write non-existing.file to the shared directory

7) GUEST: cat /media/share/non-existing.file <-- THIS SHOULD WORK NOW AS THE FILE EXISTS BUT INSTEAD SHOWS "No such file or directory"

When typing ls /media-share it shows the file with ??? for permissions, dates, etc.

If the file is written on the host BEFORE trying to access it on the guest it works as expected. If the guest tries to read the file prior to it's existence, the fact it doesn't exist is cached and the guest cannot see the file after it's been created.

This is the same for both windows and linux hosts with this guest.

Running echo 3 > /proc/sys/vm/drop_caches to clear the file cache seems to fix it.

As far as I can tell it's an issue with the file cache. I've tried recompiling the guest's kernel with various options for CONFIG_FSCACHE to no avail.

Running touch -a new.file from inside the guest makes the file visible inside the guest. I assume that mounting the folder with strictatime would also fix the problem here (as it would effectively touch the file prior to reading it) but vboxsf does not support strictatime, and norelatime,atime doesn't have the same effect.

The following configurations are affected:

Kernel 4.1 + Virtualbox Guest Modules 5.0.0
Kernel 4.2 + Virtualbox Guest Modules 5.0.0

The following are not:

Kernel 3.17 + Virtualbox Guest Modules 5.0.0

I haven't tried any others yet but it looks like this problem was introduced between 3.17 and 4.1.

I have filed this as a bug with virtualbox as well as it could be a virtualbox issue (although the same version of the virtuablox module works with 3.17 and does not work with 4.1 or 4.2)

https://www.virtualbox.org/ticket/14746