Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.
Sign up to join this community
I have Ubuntu Desktop as my main OS and Ubuntu Server as my Guest OS in VirtualBox 4.2.16.
I created a shared folder called /shared and put in it several symlinks to different folders across my main OS. Of course, my guest OS sees only broken symlinks - because these locations exist only in the main OS.
How can I make my Guest OS see the actual content of them?
Creating another shared folder is not an option.
It is a problem in virtualBox and has to do with security. Before 4.1.8 symlinks worked but was seriously flawed. And the discision was made to remove symlink support.
Symbolic link creation from within a guest has been disabled in VirtualBox 4.1.8 for security reasons. A guest could create symbolic links which point outside the assigned host directory. This has nothing to do with any ext3/ext4 bug. And the guest is still able to read symlinks which are created on the host.
Sorry for the late statement.
If you do
VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1
Then your guest will be able to create symlinks again. But for security reasons (see above) this is disabled by default. The fix to prevent dangerous symlinks from the guest is very complicated, therefore we decided to not allow any guest to create any symlink to work around the security problem.
(I took the liberty to fix a bug in the comment ;) )
Short answer is it cannot be done.
The following ticket on virtualbox.org has some clarification:
This change is intentional, and fixes a problem with the current implementation of shared folders. For compatibility with guest OSes which have no idea what a symlink is it is at the moment interpreted on the host side, and this means one get unexpected behavior with guest OSes which know what a symlink is (e.g. if a symlink on a shared folder mounted at /foo would point to /bar/file it's impossible to do the right thing on the host side).
It's of course fixable, but far from trivial as the separation of symlink processing between guest OS side and host side needs to be redesigned. This can't be done quickly, so the only option was to disable symlink creation. Too many users/applications were caught by surprise by the non-standard behavior.
