Shared Folders copying .exe files results in "The request is not supported."

[Gagome]

I run Windows 10 as guest.
Host is either Win10 too or Fedora 29.
VirtualBox is version 6.06.

On both guests I have setup Shared Folders with Full Access. When I try to copy some .exe or .dll files into any directory on the host I get errors:

The request is not supported.

Example:
I open a command prompt on the guest.
I change to the shared folder drive Z: and cd into a directory.
Then I change to the C: drive and cd into Windows.
From there I do a simple copy *.exe z:

Result:

Code: Select all

C:\Windows>copy *.exe z:
bfsvc.exe
The request is not supported.
cwbback.exe
The request is not supported.
cwbrest.exe
The request is not supported.
cwbrxd.exe
The request is not supported.
cwbunrse.exe
The request is not supported.
cwbviewr.exe
The request is not supported.
cwbzip.exe
The request is not supported.
explorer.exe
The request is not supported.
HelpPane.exe
The request is not supported.
hh.exe
The request is not supported.
isamunin.exe
The request is not supported.
notepad.exe
The request is not supported.
regedit.exe
The request is not supported.
rmtcmd.exe
The request is not supported.
RtsCM64.exe
splwow64.exe
The request is not supported.
winhlp32.exe
The request is not supported.
write.exe
The request is not supported.

Is this working-as-designed?

What is the purpose to prevent copying .exe files to the host?

[socratis]

We need to see a complete VBox.log, from a complete VM run, where the problem occurs:

• Start the VM from cold-boot (not from a paused or saved state) / Observe problem / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

What is the purpose to prevent copying .exe files to the host?

Any 3rd party antivirus?

[mpack]

I'm not seeing a demonstration that the command works with other file types.

[Gagome]

Attached is the log file what you requested.

Tests done:

Code: Select all

C:\Windows>copy *.exe z:
bfsvc.exe
The request is not supported.
cwbback.exe
The request is not supported.
cwbrest.exe
The request is not supported.
cwbrxd.exe
The request is not supported.
cwbunrse.exe
The request is not supported.
cwbviewr.exe
The request is not supported.
cwbzip.exe
The request is not supported.
explorer.exe
The request is not supported.
HelpPane.exe
The request is not supported.
hh.exe
The request is not supported.
isamunin.exe
The request is not supported.
notepad.exe
The request is not supported.
regedit.exe
The request is not supported.
rmtcmd.exe
The request is not supported.
RtsCM64.exe
splwow64.exe
The request is not supported.
winhlp32.exe
The request is not supported.
write.exe
The request is not supported.
        1 file(s) copied.

C:\Windows>copy *.log z:
comsetup.log
DPINST.LOG
DtcInstall.log
PFRO.log
setupact.log
setuperr.log
Synaptics.log
Synaptics.PD.log
SynInst.log
WindowsUpdate.log
       10 file(s) copied.

You can see that .log files are copied just fine.
Only .exe and .dll files (maybe others too? I only tested exe and dll) are not copied.
But if you look carefully you will see that one .exe file RtsCM64.exe was copied successfully. I have no idea why.

The only Antivirus program which is installed and in use is Windows Defender.
And when I use NET USE to get to an external SMB host I can copy any file without any problem to this SMB host.

This problem only affects shared folders which are on the VirtualBox host.
And it began with VirtualBox version 6. I saw it in 6.02, 6.04 and now in 6.06.
Maybe I should try to install the VBoxGuestAdditions.iso version 5.28?

I hope you can see something in the attached log.

Thanks.

[mpack]

I doubt that changing the Guest Additions will make a difference. This seems like a host OS security / folder permissions issue to me. And it will be the host OS which is enforcing it, not VirtualBox - which really couldn't care two hoots what files you copy to where.

If you examine "RtsCM64.exe" you'll probably discover why it was exempt, e.g. perhaps it isn't an executable file at all, despite the name. That file does not seem to exist in my Win10 host's "C:\Windows" folder.

[Gagome]

But how should any host OS folder permission have such an effect that .log files are allowed and .exe files are not allowed?
And I see this problem on two hosts:
One is Windows 10 Pro and the other is Fedora 29.
On both the guest is Windows 10 Enterprise. But a different image of course.

On the win10 host the shared folder is owned by me the user which is logged on and there are no special permissions present.
I have even created a second shared folder on the host and I have set the permission of this folder to full access for Everyone. And the same problem happens.

On Fedora 29 the shared folder is the home directory of the logged on user. Again there are no special permissions present.
The logged on user is the on who is starting the VirtualBox guest.

This did work flawlessly with previous versions of VirtualBox.
I use VirtualBox since version 4.3. Mostly on Fedora host.
And I first saw this problem after I upgraded VirtualBox on Fedora host to version 6.
Then I installed VirtualBox 6 on Windows 10 Pro and tested a Win10 guest and found the same problem.

I have tried with VBoxGuestAdditions 5.2.28 on the guest and I have the same problem with this previous version.

Any idea?

[Martin]

Do you have any antivirus or other security software running in the guest and/or host?

[Gagome]

Windows 10 (host and guest) is running Windows Defender and on Fedora there is no Antivirus SW installed.
Windows 10 host has additionally Malwarebytes installed.

Shared Folders from the guest to an SMB host do not have that problem. Only shared folders from VirtualBox.
Therefore I believe this is a VirtualBox problem.

Am I the only one experiencing this?

[mpack]

Am I the only one experiencing this?

I believe so.

As I said previously, there is no feature in VirtualBox which filters file copies based on type. In fact VirtualBox has no concept of file type, all it has is a more or less standard shared folder API. And anyway why would VirtualBox shoulder a host security responsibility?

This is going to be a host folder permissions, host user permissions, or AV filter issue. No two ways about it.

Does the "feature" still reject the exe if you wrap it in a zip? I'm not suggesting this as a workaround, but examining the contents of zips (specifically) is a common AV feature.

Another interesting test: take a known non-executable (say a text file), rename it to something.exe, and try copying that. My bet is that it will not be blocked, because something on the host is parsing the contents, not just using the extension.

[andyp73]

Am I the only one experiencing this?

I have just run a quick test on my Windows 10 guest running on a macOS 10.14.3 host with VirtualBox v6.0.6.

If I try to copy .exe files from C:\Windows to the directory on my shared folder (Z:\test) then the standard Windows .exe files fail with the error message you reported in the original post. My C:\Windows directory appears to have two Python executables that have been installed in it (py.exe and pyw.exe) and they copied without problem.

Copying .exe files from a non-Windows directory (in this case C:\DevTools\Cygwin\bin) was working without problem until something cause the guest to reboot. That is a whole different issue for a whole different thread when I figure out what is going on.

In regard to your issue, why do you need to copy .exe files from the Windows directory onto a shared folder?

-Andy.

[Gagome]

So, you have the same error message like me when you copy .exe files from c:\windows?
Then this is a problem in VB.

I have no real reason to copy .exe files from C:\Windows. I did this only to show the problem.
What I did was I tried to copy some files from a directory in C: to Z: (the shared folder) and all were copied except some .exe and .dll files.
That was new and never happened before.
And that was the reason why I did the tests and opened this thread.

I still believe this is a bug in VB (or a feature?).

I can copy some .exe files from different sources to the shared folder without problems. But not all. I have not found any reasonable explanation why some work and some are blocked.
And I can put the .exe files into a zip file, copy the .zip file and unzip it in the shared folder; this works.
This alone makes this blocking completely incomprehensible.

[Gagome]

Am I the only one experiencing this?

I believe so.

Have you tested with a Win10 guest?

Try my simple test and tell me the result using VB 6.06.

[mpack]

I don't have any Win10 guests.

I know that in the past I've copied exe files out of "C:\Windows" from an XP guest into a shared folder, specifically the solitaire game that was dropped from later Windows version. No problem encountered.

Does the executable copy to anywhere else inside the guest? Or is it simply that Win10 has tried to stop people copying executables to non-standard locations?

[Gagome]

I can copy from C:\Windows without any problem any file to any other folder inside the guest.
Only when I copy to the host using shared folders from VB it failes.

When I use NET USE to mount a share of the host to the guest I then have two shares.
One from VB and one which uses native SMB from Win10. Both point to the host.
I can then copy without any problem any .exe file from the guest to the SMB share on the host.
When I use the VB share it fails.

I believe this can only be a bug or feature from VB.
I see no valid reason to block this.

[mpack]

It isn't a huge mystery that different shared folder APIs have different permissions: Windows has the concept of trusted and untrusted networks.

I just tried it with a Win7-64bit guest. Again no problem.