I have Ubuntu Desktop as my main OS and Ubuntu Server as my Guest OS.

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.

-
What version virtualbox? –  Rinzwind Apr 11 '14 at 7:29
VirtualBox 4.2.16 –  dev9 Apr 11 '14 at 7:32
here you go @dev9 :) –  Rinzwind Apr 11 '14 at 7:39

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 ;) )

• and also take note that you need to restart vBox for the change to activate.
-
I executed this command and restarted VB. The color of the symlink has changed, but now I cannot even cd into it. I see it when I use ls, but bash stopped showing me it on TAB. –  dev9 Apr 11 '14 at 7:49
Hmm sounds like it is not executable? –  Rinzwind Apr 11 '14 at 7:53
Well, ls shows me lrwxrwx---, so it should be fine. When I try to cd into it, bash tells me no such file or directory. –  dev9 Apr 11 '14 at 7:56

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.

Source

-