"Il percorso specificato non esiste"

[Andrew_VB]

Buongiorno a tutti

Su Win 10 uso una macchina virtuale con Win 10

Ho condiviso una cartella dove sono presenti programmi portable

Il mio problema è che alcuni funzionano e alcuni no

Quelli che non funzionano, quando lancio il file .exe mi da l'errore

"Il percorso specificato non esiste"

Chi mi può aiutare

Seguendo altre guide ho già abilitato Direct SMBA e aggiunto una chiave nel registro di sistema

Grazie

[mpack]

Please choose a VM which does not work and provide a VM log for it. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

I would also like a screenshot of the error message, and a screenshot showing that the "path which does not exist" in fact does exist.

[Andrew_VB]

Please choose a VM which does not work and provide a VM log for it. Make sure the VM is fully shut down, then right click it in the manager UI. Select "Show Log" and save "VBox.log" (no other file) to a zip file. Attach the zip here.

I would also like a screenshot of the error message, and a screenshot showing that the "path which does not exist" in fact does exist.

Attached the screenshot and the zip with log file.

Thanks

[scottgus1]

You have working Guest Additions and a successful Virtualbox shared folder, auto mounted as drive Z.

The "TCP_IP_Manager" app has the "Run As Administrator" overlay on its icon, which means it will ask to Run As Administrator when the app runs.

The drive letter mounting of the shared folder does not exist in other accounts on the VM OS, only in the account you logged on in the VM OS. However, apps that Run As Administrator move into a different account when running. So the mounted drive letter does not exist in the Run As Administrator account, and the file cannot be run. This is a function of Windows, not Virtualbox, and cannot be changed.

You have a couple of options:

• Forget about the drive letter mount and use the \\vboxsvr "server" instead. \\vboxsvr will run in all accounts.
• Find out how to mount the shared folder to a drive letter in a Run As Administrator account. See https://superuser.com/questions/1248629 ... le-user-pc or a web search for ideas.

A consideration:

00:00:09.104722 Host path 'C:\', map name 'C_DRIVE', writable, automount=true, automntpnt=, create_symlinks=false, missing=false

You've writeable-shared the entire host C drive. This is an extremely serious security problem. You should not share the whole C drive. Any malware or runaway process in the VM could damage your host OS, not to mention full write access to the VM's own files. Mount a folder on the C drive instead, which will contain only files you want the VM to be able to write to or randomly destroy.

[Andrew_VB]

You have working Guest Additions and a successful Virtualbox shared folder, auto mounted as drive Z.

The "TCP_IP_Manager" app has the "Run As Administrator" overlay on its icon, which means it will ask to Run As Administrator when the app runs.

The drive letter mounting of the shared folder does not exist in other accounts on the VM OS, only in the account you logged on in the VM OS. However, apps that Run As Administrator move into a different account when running. So the mounted drive letter does not exist in the Run As Administrator account, and the file cannot be run. This is a function of Windows, not Virtualbox, and cannot be changed.

You have a couple of options:

• Forget about the drive letter mount and use the \\vboxsvr "server" instead. \\vboxsvr will run in all accounts.
• Find out how to mount the shared folder to a drive letter in a Run As Administrator account. See https://superuser.com/questions/1248629 ... le-user-pc or a web search for ideas.

A consideration:

00:00:09.104722 Host path 'C:\', map name 'C_DRIVE', writable, automount=true, automntpnt=, create_symlinks=false, missing=false

You've writeable-shared the entire host C drive. This is an extremely serious security problem. You should not share the whole C drive. Any malware or runaway process in the VM could damage your host OS, not to mention full write access to the VM's own files. Mount a folder on the C drive instead, which will contain only files you want the VM to be able to write to or randomly destroy.

I solved using \\vboxsv

Thank you so much

For the second, yes, i just removed the C: drive and shared only the directory that i need

[scottgus1]

Great! Glad you're up and running.

[fth0]

The drive letter mounting of the shared folder does not exist in other accounts on the VM OS, only in the account you logged on in the VM OS. However, apps that Run As Administrator move into a different account when running. So the mounted drive letter does not exist in the Run As Administrator account, [...]

FWIW, this argumentation IMHO is flawed in the common case of using UAC without having to enter credentials: Open a Windows Command Prompt with "Run As Administrator" and see for yourself (e.g. entering "Z:").

[scottgus1]

fth0, interesting point! FWIW on my Windows 10 workstation my account is an admin account. I don't have to enter a password when I run an app as admin. I have a shared folder from my file server mapped to my W: drive.

When I open the main Virtualbox window normally, go to Machine > Add, and go to "This PC", the W: drive is seen.

When I open the main Virtualbox window Run As Admin and answer Yes to the UAC prompt, I then do not see the W: drive in Machine > Add showing "This PC".

Other apps behave the same way: drive-letter-mounted shared folders show in regular operation but not when running as Admin.

I opened a command prompt Run As Admin, and entered W:, and got "The system cannot find the drive specified." A regular Command Prompt switched to the W: drive. Other physical drives in the PC showed normally in both regular and RaA Command Prompts.

This fits what I've seen about Run As Admin switching out of an account (at least in a sense) where a shared folder was drive-letter-mounted. I don't know if this behavior is different from what you were mentioning, though, or my UAC settings are not what you have. Mine are the Windows default 3rd-highest level "Notify me only when apps try to make changes to my computer".

[fth0]

It sounds like you're comparing two different kind of Apples (not Apples to Oranges ): Host-side network mount instead of guest-side VirtualBox Shared Folder mounts. Note that VirtualBox uses its own Shared Folder driver to create the virtual network access, so its quite different from e.g. SMB network shared folders.

Regarding the UAC settings, my Windows 10 Pro guest OS uses the default settings, which I would call the 2nd-highest level ("Nur benachrichtigen, wenn von Apps Änderungen am Computer vorgenommen werden (Standard)."). But even setting the highest level doesn't make a difference in the following behavior: I press and release the Win key, enter "cmd" into the search box, select "Als Administrator ausführen" from the offered alternatives, get the UAC prompt, select "Ja", enter Z: in the new command prompt window and it simply works. If you haven't done so already, please try it inside a Windows guest, I'm curious.

What I was hinting at with the credentials is that you can set an additional group policy so that the UAC dialog asks for username and password every time. With this setting in place, a new admin session is created after the UAC login prompt and it doesn't know the drive mapping. But with the default UAC settings in place, both the user session and an additional admin session were already created beforehand at the initial Windows user login, so it might be possible for VirtualBox to add the drive mapping to both sessions.

[scottgus1]

If you haven't done so already, please try it inside a Windows guest, I'm curious.

Your curiosity was well-founded! In a 7.0.6 Windows 10 host, and a Windows 7 VM with 6.1.97 GAs the auto-mounted Z: Virtualbox shared folder was accessible in both regular and Run-As-Admin command prompts. Learned something new today!

So GAs apparently auto-mount the shared folder in both regular and RaA contexts. It certainly looks like I may have been barking up the wrong tree!

[fth0]

Learned something new today!

Me too, thanks!

You made me realize that using the UNC path instead of the drive mapping can serve as a workaround for the year-old bug preventing the execution of binaries inside VirtualBox Shared Folders. I previously didn't believe that because I already new that the argument with the drive mapping is wrong. But after your suggestion I tried it myself and got convinced.

This insight could help to narrow down the bug in the VirtualBox source code of VBoxSF.sys, which is so unreadable that even @klaus would need a debugger to find the root cause.