Problem transferring files to the shared directory, maybe a hardening issue

[boxer01]

I’m trying to copy some files from the VM to the shared folder. The host is Windows 10 1709, guest is Windows 10 1703 at the beginning, later updated to the 1709 with same issue. I can’t copy the directory: the process is finished in couple of seconds, but no files or sub-directories are copied, only the root directory which I try to copy anyway. There are no error messages at all — the whole process is simply ended as it was really done. If I archive the files in the VM and copy only one archived file, then everything is OK.

I upload all the log files a got here. I also tested this with 5.1.30, 5.1.34 and 5.29, but I still have this issue. I see some error messages in the logs caused by hardening. Maybe this is a reason of all this situation, I already posted another ticket #17455 a couple of months ago, where I also had some problems because of shared folders and hardening, but this time on the host.

[boxer01]

VBox 5.2.9 Windows 1709 guest hardening log

[boxer01]

Rest if the logs, 5.1.30, 5.1.34, 5.2.8 & 5.29 with 1703 and 1709 guests

[rodcar]

I verified this.

I had two guest VMs - 1) win10 ver 1709 and 2) win10 ver 1511. (Host is win10 ver 1709)

Copying from VM #1 to sharedfolder failed as described by boxer01. VM #2 did not.

I upgraded VM #2 to ver 1709 and it to then failed just like VM #1.

RO

[JLB]

Same as bug #17859 ?

[boxer01]

JLB, you are completely right. I tested this once again, meanwhile on the current 1803 Windows 10 guest and host with the same results. Then I looked into the copied folder (a portable apps installation folder) and saw an “.nomedia” file here. As soon as this file was deleted and after reboot of the guest a could copy the folder from guest to the host without any problems. Afterwards it wasn’t a problem to copy this folder back. So all of this hidden Linux files and folders with period in the front of the name causes right now file operation problems in the Windows guests.

In my case the whole shared folder subsystem stays in the error state till the next reboot afterwards. So no file operations with shared folders could be executed til the guest reboot, even the ones without period files and folders in it.

[JLB]

It's a very annoying bug : files beginning with a dot are very common nowadays even in Windows environment.

[boxer01]

Because of some other problems with shared folders I looked for other tickets here and found some other tickets for this issue. This one (#17067) looks really alike and this one (#16762) is exact the same problem. Both of them over a year old.

[bblackmoor]

I have this same problem. This is NOT caused by a leading dot in a file name or directory name, because there are not any.

• Host is Windows 10 Pro x64.
• Guest is Windows 10 Pro x64.
• VirtualBox is VirtualBox-6.0.4-128413-Win

D:\Documents\Downloads is shared from the host to the guest, as "Downloads", which I have assigned to Z: in the guest OS.

Opening two file windows in the guest, one at C:\Downloads, the other at Z:

Select four directories in guest window. Attempt to copy and paste, or drag and drop, to the shared folder copies only the first directory, and does not copy any of its contents.

Repeated copy/paste or drag/drop will copy the next (empty) directory, and then the next, and so on until all of the directories have been copied. After that, the next copy/paste or drag/drop will copy the directory contents.

This is a new problem for me: everything worked fine a week ago.

I have:

• Updated VirtualBox from 5 to 6 (I was using 5 when this problem first appeared).
• Installed the new extension pack (copy/paste or drag/drop will copy the next (empty) directory).
• Re-installed the Guest Additions several times.

I am sorely vexed.

See also: https://www.virtualbox.org/ticket/17067

[bblackmoor]

I removed the shared folder, rebooted the VM, and re-created the shared folder. Same problem.

[boxer01]

Replying to bblackmoor:

Sorry, but you have a different issue which has nothing to do with the issue described here. The only common part is the shared folders system. Because socratis would tell you “one issue per ticket”, I opened another one with only this problem: #18566. Quick overview: my Windows 7 guest is unaffected, only the Windows 10 guests with current updates are.

[bird]

Haven't quite been able to reproduce this yet, but current suspect is that directories with non-default attributes (like hidden) set might get us into trouble as shared folders would silently ignore requests for modifying attributes on directory (works fine on files).

PS. #17859 was closed as a duplicate of this ticket.

[bird]

A scenario for reproduction with 6.0.8 GAs and 6.0.8 VBox host would be very helpful here. I've tried with both win10-1709 and win10-1803 guest and it only happens once or twice, then it starts working consistently.

[boxer01]

I’ve tested with current versions of Virtual Box, such as 6.0.8 / 6.0.9 (130520, 130868, 130970) and 5.2.30 / 5.2.31 (130521, 130748, 130893). This issue is gone, at least on my Windows 10 1809 guest and host combination. Now I couldn’t reproduce it. And because of probably the same changes or the same issue source my other ticket #18566 is also solved, at least for me. It would be nice to have some responses from other peoples.

[boxer01]

Replying to bird:

As I wrote, this looks corrected in the latest 6.0.8 and 5.2.30 versions, you could reproduce this with earlier versions. I upload my “.nomedia” file here. If you put it in some directory, then you can reproduce this problem and this directory wouldn’t be copied in any direction, host to guest or vice verse. And no, this file has no special attributes on my system, neither hidden nor system or something else. It is simply Linux hidden by the name.

[boxer01]

7zip file with ".nomedia" file inside