VirtualBox

Ticket #9318 (closed defect: fixed)

Opened 3 years ago

Last modified 15 months ago

Shared Folders - Cannot copy to VM, but can access shared foldes

Reported by: brhahlen Owned by:
Priority: major Component: shared folders
Version: VirtualBox 4.1.0 Keywords:
Cc: Guest type: Windows
Host type: Linux

Description (last modified by frank) (diff)

When using the Shared Folders feature, with the SF mounted through the net use command, you are unable to copy files to the guest. The resulting error is a 0x80070057: The parameter is incorrect. This did not occur when accessing the same folder through Samba Shares.

Guest Additions are installed.

Attachments

VBox.log Download (77.9 KB) - added by brhahlen 3 years ago.
VBox.log
copy_error.png Download (26.6 KB) - added by brhahlen 3 years ago.
Screenshot of error when copying
copy_vs_xcopy_for_9318.CSV Download (138.5 KB) - added by wnicholls 3 years ago.
Proc mon log file for copy and xcopy of an exe and then copy of a txt
shot_247.png Download (15.5 KB) - added by wnicholls 3 years ago.
Screenshot: installing MSI from share drive - I suspect this is related
VBox-scorpio-wnicholls.log Download (81.3 KB) - added by wnicholls 3 years ago.
Last run
VBox.2.log Download (85.7 KB) - added by pshrutpark 3 years ago.
As requested by sunlover

Change History

Changed 3 years ago by brhahlen

VBox.log

Changed 3 years ago by brhahlen

Screenshot of error when copying

comment:1 Changed 3 years ago by sunlover

Which Windows version do you use as the guest? How do you copy the file? Using Drag and drop from a shared folder to the local drive in the guest?

comment:2 Changed 3 years ago by brhahlen

Whoops... Sorry about that. Host : Fedora 14, x86_64 Guest: Windows 7, x86_64

Copying file: Tried both via CTRL-C/CTRL-V and drag&drop. The copying is from a shared folder (\VBOXSVR\share) to a local drive (My Documents) in the guest. The shared folder is mapped to a drive, using

net use X: \VBOXSVR\share

Using samba, and using the same command to map the share, only then with the server name, it works without a problem.

comment:3 Changed 3 years ago by wnicholls

I can confirm this. Sort of..

Host: Kubuntu Natty 64-bit (fully up-to-date as of 2011-Jul-28) Guest: Windows 7 Professional SP1 64-bit VirtualBox Version: 4.1.0-73009~Ubuntu~natty (from APT repo  http://download.virtualbox.org/virtualbox/debian )

C: is a virtual SATA hard disk D: is a shared folder from the host net use d: \vboxsrv\DataShared

Copy does not work, XCOPY does:

 c:\> copy d:\file c:\file 
 The parameter is incorrect.
          0 file(s) copied

but

 c:\> xcopy d:\file c:\file 
 1 File(s) copied

Does not matter whether logged in normally or using a command prompt with elevated permissions.

HOWEVER when I tried to set up a test from c:\temp\ to d:\temp\ I did not have any such issue - worked in both cases. So there is something about the file. I can't tell what.

From the linux side, permissions are -rw-r--r-- on both files, drwxr-xr-x on both directories, and I am owner & group of both. The only difference is the failing file is one I *WANT* to copy, and the working file is my test junk file which I care nothing about!

comment:4 Changed 3 years ago by wnicholls

More. . the name of the file matters... Try this one for size:

D:\temp>dir temp.exe
 Volume in drive D is VBOX_DataShared
 Volume Serial Number is 0000-0807

 Directory of D:\temp

22/03/2011  01:05 p.m.         4,312,397 temp.exe
               1 File(s)      4,312,397 bytes
               0 Dir(s)  24,861,093,888 bytes free

D:\temp>copy temp.exe c:\temp\
The parameter is incorrect.
        0 file(s) copied.

D:\temp>ren temp.exe temp.dat

D:\temp>copy temp.dat c:\temp\
        1 file(s) copied.

So when the file was called something.exe it failed, something.dat (.txt etc) worked.

Don't know if that sheds light .. I will now say not that this wasn't happening under VirtualBox 4.0 just that I didn't NOTICE then.

I've had similar issues trying to install software from a shared folder (eg d:\downloads\setup.exe) - copying to C: drive solved the problem. at the time I put it down to some kind of Windows 7 trust issue but now I think it was probably this problem.

comment:5 follow-up: ↓ 6 Changed 3 years ago by brhahlen

I never thought of using xcopy... Actually didn't use the command-line to try.

I am pretty sure it's not a rights issue, as I can access the files no problem using a Samba share. Also, opening any document, like a Word doc, Excel sheet or Quicken db, does not work. Again: using Samba does not give these issues.

Also, I've tried with multiple files on different locations and they all run into this issue. As said above, copying files from guest to share works without a problem. Copying back doesn't work then, but I need to confirm that.

Opening .exe's from any location, whether VBoxShare or Samba, is a problem, so I think that is a Win7 issue.

comment:6 in reply to: ↑ 5 Changed 3 years ago by brhahlen

Replying to brhahlen:

I never thought of using xcopy... Actually didn't use the command-line to try.

I am pretty sure it's not a rights issue, as I can access the files no problem using a Samba share. Also, opening any document, like a Word doc, Excel sheet or Quicken db, does not work. Again: using Samba does not give these issues.

Also, I've tried with multiple files on different locations and they all run into this issue. As said above, copying files from guest to share works without a problem. Copying back doesn't work then, but I need to confirm that.

Opening .exe's from any location, whether VBoxShare or Samba, is a problem, so I think that is a Win7 issue.

Just confirmed that copying to the VBoxShare works, but then copying the exact same file back fails.

comment:7 follow-up: ↓ 8 Changed 3 years ago by sunlover

We could not reproduce the problem here, unfortunately.

wnicholls, which host folder is mapped to D:? Could you also post the listing of the host's temp directory, where the temp.exe is located (ls -l)? What happend when you rename temp.dat to temp.exe again and try to copy it to the guest?

brhahlen, can you confirm that using the command line 'copy' does not work too?

comment:8 in reply to: ↑ 7 Changed 3 years ago by brhahlen

Replying to sunlover:

We could not reproduce the problem here, unfortunately.

wnicholls, which host folder is mapped to D:? Could you also post the listing of the host's temp directory, where the temp.exe is located (ls -l)? What happend when you rename temp.dat to temp.exe again and try to copy it to the guest?

brhahlen, can you confirm that using the command line 'copy' does not work too?

Yes, I can confirm that the command line copy does not work either. Actually: xcopy does not work for me as well. Also get "the parameter is incorrect".

comment:9 Changed 3 years ago by brhahlen

I am definitely calling this a VBoxSharedFolder bug.

Situation: Host with two mapped drives:

O: - VBox  - \VBOXSVR\Ben - maps to folder on Server /home/storage/Ben
Q: - Samba - \Server\Ben  - maps to folder on Server /home/storage/Ben

I am able to copy files from the Q: drive to the guest no problem. Copying from the O: drive to the guest poses this problem. My user on the Fedora Host, running vbox, is in the vboxusers group. And read/write is set on the Shared Folder.

comment:10 Changed 3 years ago by wnicholls

Information requested on my setup (some from memory as I don't have the Windows VM running right now).

\vboxsrv\DataShared folder is mapped to /data/ which is an ext4 partition. If the running-setup-programs thing I mentioned is related then that is another shared folder mapped to /home/walter/my/downloads/ - /home being another ext4 partition, here's what mount shows:

/dev/sda7 on /data type ext4 (rw,commit=600)
/dev/sda6 on /home type ext4 (rw,commit=600)

Thus d:\temp\ is /data/temp .. I don't think there is much to be gleaned from this as it is just a big dumping ground / transfer area, but since you asked here's a small flavour of it:

walter@haven:~$ ls -l /data/temp
total 1387032
-rw-rw-rw- 1 walter walter    126339 2011-03-29 14:32 94770280 2011-02-28.pdf
-rw-r--r-- 1 walter walter    384844 2011-07-12 15:41 9I0XMWNP.pdf
-rw-rw-rw- 1 walter walter     19162 2011-04-11 23:57 aamxcli_20110311.zip
-rw-rw-rw- 1 walter walter     15683 2011-03-30 15:59 aamxcli_20110330.zip
-rw-r--r-- 1 walter walter       286 2011-06-21 12:31 affected.txt
  ... etc etc ...
-rw-rw-rw- 1 walter walter 4312397 2011-03-22 14:05 /data/temp/temp.exe
 ... etc ..

I renamed back and forth between temp.dat and temp.exe several times with same effect, while called exe it didn't work. There must be something different about COPY's (and the Explorer/shell) behaviour when copying executable files .. If I get a chance, I'll run procmon (sysinternals) and see if that shows something up, but am busy tomorrow.

From memory, I concur that copying from vbox shared folder fails, to shared succeeds. I haven't looked closely if other file types (.com, .cmd etc) exhibit the same behaviour. Also for completeness I did investigate file size and a couple of other things.

HTH - Walter

comment:11 Changed 3 years ago by brhahlen

Also: what I have noticed in the setup now, is that if you get a "Save as" dialog, it shows the name of the Samba-share (e.g.: "Docs (\Server\Ben) (Q:)", but for the VBox Share it only says "Disconnected Network Drive (O:)". Not sure if it is related thought, just something I spotted just now.

comment:12 Changed 3 years ago by wnicholls

Copying from shared drive to shared drive also fails, etc

copy d:\temp\temp.exe d:\temp\temp2.exe

Also here's a good one, from command prompt with D: as current drive, typed procmon - dialog box sayws "Unspecified error". Change to C: drive, type procmon and it runs as expected. procmon.exe is on the C: drive.

Don't know if it helps but I with procmon running I executed the following commands

copy d:\temp\temp.exe d:\temp\temp2.exe
xcopy d:\temp\temp.exe d:\temp\temp2.exe
copy d:\temp\temp.txt d:\temp\temp2.txt

Attached is the log file copy_vs_xcopy_for_9318.csv (filtered for cmd.exe and xopy.exe only) .. lots of data, I don't have time to browse it right now. (procmon = Process Monitor from sysinternals.com)

Changed 3 years ago by wnicholls

Proc mon log file for copy and xcopy of an exe and then copy of a txt

Changed 3 years ago by wnicholls

Screenshot: installing MSI from share drive - I suspect this is related

comment:13 Changed 3 years ago by sunlover

Thanks a lot for the additional information, especially for the procmon log. It shows that copying of test.exe is indeed different.

comment:14 Changed 3 years ago by sunlover

wnicholls, how much guest RAM has the Windows 7 VM? And please attach VBox.log of the VM as well. Thanks!

comment:15 Changed 3 years ago by wnicholls

How much guest RAM has the Windows 7 VM? - 1 GB

Changed 3 years ago by wnicholls

Last run

comment:16 Changed 3 years ago by wnicholls

Cannot reproduce on Windows XP guest with 4.0.4 guest additions or (after upgrading) with 4.1.0 guest additions. All copy directions and types of file work.

comment:17 Changed 3 years ago by wnicholls

Aha... I should have thought of this earlier.. With AVG 2011 Antivirus running:

D:\temp>copy temp.exe c:\temp\
The parameter is incorrect.
        0 file(s) copied.

With AVG temporarily disabled (if you have AVG it is in the Advanced Settings , third from bottom in the list):

D:\temp>copy temp.exe c:\temp\
        1 file(s) copied.

I've searched the AVG forums and can't find any reference to this sort of problem, and as observed regular network drives to do not exhibit the same behaviour, so not put down to a solely antivirus problem but that could explain why you can't easily repro it.

comment:18 Changed 3 years ago by sunlover

wnicholls, good findings.

brhahlen, do you also have some antivirus software in the VM?

comment:19 Changed 3 years ago by brhahlen

Yes, I use Comodo Internet Security. Same thing happens as with wnicholls. If I turn the AV part of it off, I can copy files no problem. When I turn it on again, however, it just fails.

comment:20 follow-up: ↓ 21 Changed 3 years ago by draptik

I can confirm this behaviour (AV: Microsoft Security Essentials).

Deactivating AV software -> no problem.

(this is a regression bug, since this worked with VirtualBox 4.0.12)

Host OS: Ubuntu 11.04 64bit Guest OS: Windows 7 Prof. 64bit VirtualBox 4.1

comment:21 in reply to: ↑ 20 Changed 3 years ago by pshrutpark

Same problem upon updating to 4.1, but using OS X host and Windows 7 64 bit guest (Win 2000 guest is fine). From within the Guest, can not copy or open files on host via VBoxShare and get the error code and message saying the file(s) trying to copy are corrupt. The virtual box shared folder component appears to be the source of the problem because "regular" LAN access works fine.

Within the Win 7 guest my set of mapped drives were listed as per normal but a duplicate set with different drive letter mapping were also generated when using 4.1.

Reverted to 4.0.12 and everything works fine."

Microsoft firewall and antivirus used in 4.1 and previous releases.

comment:22 follow-up: ↓ 23 Changed 3 years ago by wnicholls

Hmm. Some more evidence although it might be a distraction.

  1. There is a similar discussion on #5732 noting different behaviour between samba network shares and vbox shared folders. (That problem is a better description of my "install software from a shared folder" hunch: UAC elevation issues)

  1. I also just tried this from an administrator command prompt:
    c:\> net use d: \vboxsrv\datashared
    System error 53 has occurred.
    
    The network path was not found.
    }}
    If I try mapping the drive from an elevated net useWindows Explorer, it shows the non-elevated drive mapping, and just hangs. 
    
    I think it is reasonably clear there are some .. shortcomings .. in the virtualbox virtual network redirector. With perhaps multiple symptoms?
    

comment:23 in reply to: ↑ 22 Changed 3 years ago by wnicholls

Replying to wnicholls: Oops that should have been "from an elevated Windows Explorer .. just hangs"

comment:24 follow-up: ↓ 25 Changed 3 years ago by sunlover

pshrutpark, have you reverted to 4.0.12 both VBox and the guest additions, or only VBox? Please attach VBox.log of the VM.

comment:25 in reply to: ↑ 24 Changed 3 years ago by pshrutpark

Replying to sunlover:

pshrutpark, have you reverted to 4.0.12 both VBox and the guest additions, or only VBox? Please attach VBox.log of the VM.

Both VBox and the Guest Additions.

Changed 3 years ago by pshrutpark

As requested by sunlover

comment:26 follow-up: ↓ 27 Changed 3 years ago by wnicholls

I downgraded to Virtualbox 4.0.12 and all these problems seemed to have gone away. Still running 4.1 guest additions.

  • copy exe from shared folder (net use \vboxsrv\...) to local hard disk (VDI)
  • net use .. \vboxsrv from an elevated command prompt ; and mapping drive letter from Windows Explorer
  • AND a problem I hadn't told you about with a Foxpro program that ran from d:\ command prompt but NOT from within the Visual Foxpro IDE! (a really wacky problem but again, associated with reading from EXE file on the shared drive)

That's two of us now... regression from 4.0.12

comment:27 in reply to: ↑ 26 Changed 3 years ago by VGib

I confirm the bug, on my VM host Windows 7 64 bits with Microsoft security esential antivirus; i can't copy any file from VBOX shared folder to VM's folder. ( since the copy directory works, the file copy fails with an 0x80070057 error ). When i desactivate the antivirus it work's.

VGib

comment:28 Changed 3 years ago by TobiasMuller

Same problem, but using Mac OS X 10.7 (Lion) as the host. Client is Windows 7 64 bit with Microsoft Security Essentials enabled. If I disable "monitor file and program activity" (part of the real time protection) the problem goes away.

comment:29 Changed 3 years ago by sunlover

Thanks everyone. We reproduced the problem here. However the fix is not yet available.

comment:30 Changed 3 years ago by sunlover

BTW, can anyone of you test if this works in Windows 7 *32* bit guest. Because it looks like it works with 32 bit and does not work with 64 bit. From the comments I see that most use 64 bit Windows 7. Thanks.

comment:31 Changed 3 years ago by TobiasMuller2

It tried the same on Windows 7 32 bit now. Shared folders do work with enabled real time protection of the Microsoft Security Essentials. It is a problem with the 64 bit version only.

comment:32 follow-up: ↓ 34 Changed 3 years ago by sunlover

TobiasMuller2, thanks for the test. It confirms our findings.

There is a new guest additions build, which should work with 64 bit Windows guests:

 VBoxGuestAdditions-r73443.iso

Please test it.

comment:33 Changed 3 years ago by brhahlen

Downloading now. Will install and report back.

comment:34 in reply to: ↑ 32 Changed 3 years ago by brhahlen

Replying to sunlover:

There is a new guest additions build, which should work with 64 bit Windows guests:

 VBoxGuestAdditions-r73443.iso

Please test it.

Tested and continuing testing, but it seems to work. I can copy files to the VM from the VBOXSVR, can open files from it, etc. Nice job :)

comment:35 Changed 3 years ago by adamjanzen

Build 73443 has resolved the issue for me as well

comment:36 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

This is fixed in VBox 4.1.2.

comment:37 Changed 2 years ago by DanielM

  • Status changed from closed to reopened
  • Resolution fixed deleted

I am sorry to reopen this ticket, but it seems that I have the exact same problem with VirtualBox 4.1.6 and a Windows 7 32-bit guest with a Ubuntu 10.10 64-bit host. Disabling Microsoft Security Essentials did NOT resolve the problem. Only reverting to VirtualBox 4.0.14 allowed me to acces all files in the shared folder. The error is the same as described in the inital post, i.e., "Error 0x80070057: The parameter is incorrect." when I try to copy files from the shared folder.

comment:38 Changed 2 years ago by ratus53

Hi,

I have the same issue even though I have the version 4.1.2_ubuntu r38459. I'm running under Linux Mint 12. I tried to install both Windows 7 SP1 32 bits and 64 bits.

I tried to copy .exe and .iso files and neither worked.

comment:39 Changed 2 years ago by TDQ

I have the same issue - I can't copy files from the Mac host to the Win7 VM. I can open files using MS Office applications, and save the changes to my Mac filesystem, but I can't copy the files using Windows Explorer.

Host: Mac OS X Lion 10.7.2 (11C74) HQ: Macbook Pro (Early 2011) VM: Windows 7

This is extraordinarily frustrating.

comment:40 Changed 2 years ago by durkadurka@…

I was having the same issue but fixed it by simply installing the  Guest Additions (as mentioned shortly before the ticket was closed). Go to the Device tab and select "Install Guest Additions", and follow the installation prompts.

Host: Ubuntu 11.10 (Oneiric) 64-bit
VM: Windows 7 Enterprise 64-bit
VirtualBox version: 4.1.2_Ubuntu r38459

comment:41 Changed 2 years ago by Alduin

I have this problem on a Virtual Windows 7 x64 machine running on an OpenIndiana 151a host. I use VirtualBox 3.2.14 accompanied with the latest guest additions.

The error is intermittent and it seems that there is something that occasionally prevents the files that are shared over this virtual network to open either for read or write.

Perhaps there is a glitch in the virtual network driver (backend/frontend?) that makes it choke or behave in a bad way when there are too many "file open" requests at a given time.

To reproduce the bug, I would suggest trying to read and write randomly inside a virtual Windows machine to say 250 files of varying size between 1 and 20MB each using some kind of multithreaded approach so that there are many file open requests (for both read and write/modify) in a short period of time.

*Edit*: I also checked the .VirtualBox/Machines/<virtualmachinename>/Logs/VBox.log and the error entries I get is the following:

03:00:48.582 SharedFolders host service: Cannot open '/<pathtofile>' -- too many open files.

and I think this error is kind of self-explanatory.

Last edited 2 years ago by Alduin (previous) (diff)

comment:42 Changed 2 years ago by Wayne Sallee

This bug is caused by the virtualbox ext4 bug. And it looks like the format the mac uses is also causing virtualbox to bug out.

I can open a file in the share folder with a text editor, and then save that file to another folder, but try to copy that file from the share folder to another folder, and it will often error out.

It has to do with the type of format of the hard drive, or virtual hard drive. It does not have to do with 32 verses 64 bit.

Wayne Sallee Wayne@…

comment:43 Changed 2 years ago by frank

  • Description modified (diff)

Which ext4 bug are you talking about?

comment:44 Changed 2 years ago by Wayne Sallee

Surprisingly I have not found the ext4 bug listed in the virtualbox ticket system. That's why I came, here to see what the status is, as I've been getting tired of it.

There are many mentions of it if you google 'virtualbox ext4 bug "shared folder"'.

Maybe an official bug report needs to be made for it.

comment:45 Changed 2 years ago by frank

I still don't know which ext4 bug you are talking about. There was a problem with ext4 in Linux kernels older than 2.6.36 but this was a bug in the Linux kernel, not in VirtualBox. As I said, this bug was fixed as of Linux 2.6.36 and has nothing to do with ext4.

Version 0, edited 2 years ago by frank (next)

comment:46 Changed 20 months ago by yurivict

I also have the problem copying file in Windows guest.

E:\>copy oem.dll c:\ Access is denied.

0 file(s) copied.

E:\>

However, this file opens in notepad. Also other files in the shared directory can be run, but not copied. I am not sure why one would be able to open the file in notepad but not by copy.

virtuabox-4.1.18, FreeBSD 9.1 amd64 host. latest additions are installed.

Last edited 20 months ago by yurivict (previous) (diff)

comment:47 Changed 15 months ago by mihmax

Also had this 0x80070057 error in VirtualBox 4.2.6 and 64-bit Windows guest,

Resolved after installing guest additions. Hope this helps.

comment:48 Changed 15 months ago by sunlover

  • Priority changed from critical to major
  • Status changed from reopened to closed
  • Resolution set to fixed

Please reopen if still reproducible with VBox 4.2.6.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use