Ubuntu Desktop est mon système d'exploitation principal et Ubuntu Server est mon système d'exploitation invité dans VirtualBox 4.2.16.
J'ai créé un dossier partagé appelé/shared et y ai placé plusieurs liens symboliques vers différents dossiers de mon système d'exploitation principal. Bien sûr, mon système d'exploitation invité ne voit que des liens symboliques rompus, car ces emplacements n'existent que dans le système d'exploitation principal.
Comment puis-je faire en sorte que mon système d'exploitation invité en voie le contenu réel?
La création d'un autre dossier partagé n'est pas une option.
C'est un problème dans virtualBox et est lié à la sécurité. Avant la version 4.1.8, les liens symboliques fonctionnaient mais étaient gravement défectueux. Et la décision a été prise de supprimer le support des liens symboliques.
La création de liens symboliques à partir d'un invité a été désactivée dans VirtualBox 4.1.8 pour des raisons de sécurité. Un invité peut créer des liens symboliques pointant hors du répertoire d'hôtes attribué. Cela n'a rien à voir avec aucun bogue ext3/ext4. Et l'invité peut toujours lire les liens symboliques créés sur l'hôte.
Désolé pour la déclaration tardive.
Si tu fais
VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1
Ensuite, votre invité pourra à nouveau créer des liens symboliques. Mais pour des raisons de sécurité (voir ci-dessus), cette option est désactivée par défaut. Le correctif pour empêcher les liens symboliques dangereux de l'invité est très compliqué, nous avons donc décidé de ne permettre à aucun invité de créer un lien symbolique pour contourner le problème de sécurité.
(J'ai pris la liberté de corriger un bug dans le commentaire;))
La réponse courte est que cela ne peut pas être fait.
Le ticket suivant sur virtualbox.org apporte des éclaircissements:
Cette modification est intentionnelle et résout un problème lié à l'implémentation actuelle des dossiers partagés. Pour assurer la compatibilité avec les systèmes d’exploitation invités qui n’ont aucune idée du lien symbolique c’est actuellement interprété du côté de l’hôte, cela implique un comportement inattendu avec les systèmes d’exploitation invités qui savent ce qu’est un lien symbolique (par exemple, si un lien symbolique est monté sur un dossier partagé). at/foo indiquerait/bar/file il est impossible de faire la bonne chose du côté de l’hôte).
C'est bien sûr réparable, mais loin d'être trivial, car la séparation du traitement des liens symboliques entre le côté du système d'exploitation invité et le côté de l'hôte doit être repensée. Cela ne peut pas être fait rapidement, alors la seule option était de désactiver la création de liens symboliques. Trop d'utilisateurs/d'applications ont été pris au dépourvu par le comportement non standard.