VirtualBox

Opened 6 years ago

Closed 4 years ago

#17626 closed defect (fixed)

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

Reported by: boxer01 Owned by:
Component: shared folders Version: VirtualBox 5.2.8
Keywords: Cc:
Guest type: Windows Host type: Windows

Description

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.

Attachments (3)

529_1709_VBoxHardening.zip (128.7 KB ) - added by boxer01 6 years ago.
VBox 5.2.9 Windows 1709 guest hardening log
VBox_Share_log.zip (456.1 KB ) - added by boxer01 6 years ago.
Rest if the logs, 5.1.30, 5.1.34, 5.2.8 & 5.29 with 1703 and 1709 guests
.nomedia.7z (307 bytes ) - added by boxer01 5 years ago.
7zip file with ".nomedia" file inside

Download all attachments as: .zip

Change History (16)

by boxer01, 6 years ago

Attachment: 529_1709_VBoxHardening.zip added

VBox 5.2.9 Windows 1709 guest hardening log

by boxer01, 6 years ago

Attachment: VBox_Share_log.zip added

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

comment:1 by rodcar, 6 years ago

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

comment:2 by JLB, 6 years ago

Same as bug #17859 ?

comment:3 by boxer01, 6 years ago

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.

Version 0, edited 6 years ago by boxer01 (next)

comment:4 by JLB, 6 years ago

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

comment:5 by boxer01, 5 years ago

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.

comment:6 by bblackmoor, 5 years ago

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.

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

Last edited 5 years ago by bblackmoor (previous) (diff)

comment:7 by bblackmoor, 5 years ago

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

in reply to:  7 comment:8 by boxer01, 5 years ago

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.

comment:9 by bird, 5 years ago

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.

Last edited 5 years ago by bird (previous) (diff)

comment:10 by bird, 5 years ago

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.

comment:11 by boxer01, 5 years ago

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.

in reply to:  10 comment:12 by boxer01, 5 years ago

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.

by boxer01, 5 years ago

Attachment: .nomedia.7z added

7zip file with ".nomedia" file inside

comment:13 by bird, 4 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use