Visual Studio 2010 Doesn't Like VBOXSVR Drives
Posted: 30. Jun 2012, 07:06
Host: windows 7 Ultimate x64 SP1 with all patches
VritualBox 4.1.16
Guest: Windows 7 Ultimate X64 SP1 with all patches
No Domain -- Windows Workgroup Networking
I have:
Machine Folders
Shared V:\VirtualBox\Shared Full
Users V:\VirtualBox\Users Full
I have set the premissions on the real folders to Full Control for all Users.
In the guest I have mapped
S: ==> VBOXSRV\Shared
U: ==> VBOXSRV\Users
If I start Visual Studio 2010 and try and create a project on a folder on the S: drive Visual Studio starts the process and then aborts (windows restarts it after putting up the checking for solutions dialog box).
If I start Visual Studio 2010 and try and create a project on a folder on a drive mapped to a windows networked drive it works fine.
When I tried to check security settings I noticed that if I select the S: drive (or a folder on it) and right click and select properties the security tab is not there. It is there if I do the same thing to a folder on a drive maped to a Windows networked drive.
VBOXSRV mappings do not expose the underlying ACLs.
Is there a workaround for this?
VritualBox 4.1.16
Guest: Windows 7 Ultimate X64 SP1 with all patches
No Domain -- Windows Workgroup Networking
I have:
Machine Folders
Shared V:\VirtualBox\Shared Full
Users V:\VirtualBox\Users Full
I have set the premissions on the real folders to Full Control for all Users.
In the guest I have mapped
S: ==> VBOXSRV\Shared
U: ==> VBOXSRV\Users
If I start Visual Studio 2010 and try and create a project on a folder on the S: drive Visual Studio starts the process and then aborts (windows restarts it after putting up the checking for solutions dialog box).
If I start Visual Studio 2010 and try and create a project on a folder on a drive mapped to a windows networked drive it works fine.
When I tried to check security settings I noticed that if I select the S: drive (or a folder on it) and right click and select properties the security tab is not there. It is there if I do the same thing to a folder on a drive maped to a Windows networked drive.
VBOXSRV mappings do not expose the underlying ACLs.
Is there a workaround for this?