making a symlink fails on a shared folder with EROFS

[Vlad Bespalov]

it is impossible to create a symlink within a shared folder from guest OS.

guest shell output:

---

[user@centos sf_sources]$ mount

/dev/sda1 on / type ext4 (rw)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw,gid=5,mode=620)

tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")

/dev/sda3 on /home type ext4 (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

sources on /media/sf_sources type vboxsf (gid=501,rw)

[user@centos sf_sources]$ ln ./test ./test2

ln: creating hard link ./test2' => ./test': Operation not permitted

[user@centos sf_sources]$ ln -s ./test ./test2

ln: creating symbolic link `./test2': Read-only file system

[user@centos sf_sources]$ touch test2

[user@centos sf_sources]$ ls test*

test test2

---

host FS for the shared folder is ext4.

same operation worked fine in ver. 4.1.6

[Roger]

I can verify this behavior. I just downgraded from 4.1.8 to 4.1.6 because of it.

My details host: Max OSX 10.6.8 guest: (K)Ubuntu $ uname -a; cat /etc/issue Linux moore-u64 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 11.10 \n \l

Host fs for shared folder is hfs.

[mig5]

I reproduce this too.

Host: Mac OS X 10.7.2 (Lion) Guest: Debian 6 (Squeeze)

You *can* touch and modify files in a shared folder, on the guest, which confirms that the shared folder *is* writable, but you cannot symlink within that shared folder on the guest ('read-only filesystem').

[Tor Helge Huse]

I can reproduce this and the opposite as well - symlinks on the host are no longer accessible from the guest, something which worked fine in 3.somethingX that I recently upgraded from. (Guest Ubuntu Server 10.10, Host: ClearOS 5.2 (Centos)).

[Technologov]

+1

[NevilleDNZ@…]

Same problem:

ln: creating symbolic link `./test2': Read-only file system

Does not work with VirtualBox-4.1-4.1.8_75467_rhel6-1.x86_64.rpm

System setup is:

• VM Host: Centos 6.2 + 2.6.32-220.4.1.el6.x86_64 and
• VM Client: Centos 6.2 + 2.6.32-220.2.1.el6.i686 and

Works fine with:

• VirtualBox-4.1-4.1.6_74727_rhel6-1.x86_64

Workaround was to revert to 4.1.6 and turn off any automatic package updates.

Note:

• Saved machine states will not reload when you revert to 4.1.6.
  • (See quoted error message below)
• either do a "Full Shutdown", or "Discard Saved State".

error message:

Failed to open a session for the virtual machine tikanga. Unsupported version 2 of data unit 'HGCM' (instance #0, pass 0xffffffff) (VERR_SSM_UNSUPPORTED_DATA_UNIT_VERSION). Result Code: NS_ERROR_FAILURE (0x80004005) Component: Console Interface: IConsole

It looks very much like symbolic links were not tested. Maybe someone show add symbolic links into a rununittest somewhere? :-)

N

[iansltx]

Experiencing the same issues as NevilleDNZ@...

VM Host: Mac OS X 10.7.3 VM Client: Centos 6.2 i686

Downgrading to 4.1.6 solves the issue.

[Klaus Espenlaub]

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.

[Roger]

Replying to klaus:

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.

Isn't that what happens if you mount an NFS share? I.E. if you mounted an nfs share at /foo that contained some symlink to /bar/file then if you had a /bar/file, it would resolve to your local copy, no? If you didn't have a /bar/file, it would dangle. It isn't terribly secure, but there you go. Anyway, I don't think NFS tries to stop this.

I mention this because I depend heavily on the symlinks working on the shares and my alternative is to use an NFS server. The reason I chose VirtualBox altogether instead of ... an alternative offering... solution was precisely because this works and the shared fs thing seems to perform so much better. I was going to say that a lack of this feature is going to force me to switch to an NFS server on the host mounted on the guest but that creates more complication because I'll have to mount the same drive as CIFS for my windows guest.

I wonder what hosts don't understand sym-links also. I know NTFS knows what they are and I think there are two different methods of setting them up. So I suspect windows+fat drives?

[Klaus Espenlaub]

I thought I explained it clearly - the previous VirtualBox shared folders behavior related to symlinks was simply wrong, and this isn't primarily due to the host OS or its filesystem capabilities. If you happened to have no problems with symlinks consider yourself lucky.

[NevilleDNZ@…]

I hope you know how this sounds.... basically...

"Symbolic links works on Linux, Unix, MacOSX and BSD, but not for Windows. So for consistency it was decided to break symbolic links for Linux, Unix, MacOSX and BSD too!"

I am sure this above interpretation is wrong.

re: "shared folders behavior related to symlinks was simply wrong"

It sounds a bit like the sharer was trying to follow the link instead of passing the link details back to the sharee... Maybe you can clarify.

Without symbolic link most Linux, Unix, MacOSX and BSD apps will break. It is POSIX standard too. A stock standard vanilla RHEL6 installation has about 12500 symbolic links! Strange but true!

Good luck fixing it. If you want a hand let me know.

[Wayne Sallee]

I think this is caused by the ext4 incompatibility bug in virtual box. For example, if you have a host with ext3 and you have a guest with ext4, you will find it difficult to copy files from the share folder to the guest.

I think these two bugs might be the same.

[Frank Mehnert]

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 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.

[Klaus Espenlaub]

Replying to NevilleDNZ@…:

I hope you know how this sounds.... basically...

"Symbolic links works on Linux, Unix, MacOSX and BSD, but not for Windows. So for consistency it was decided to break symbolic links for Linux, Unix, MacOSX and BSD too!"

I am sure this above interpretation is wrong.

Your interpretation is very wrong. Symlinks were never behaving quite correctly, and this misbehavior existed on all platforms.

Without symbolic link most Linux, Unix, MacOSX and BSD apps will break. It is POSIX standard too.

Doesn't mean much - filesystems may or may not implement symlinks.

A stock standard vanilla RHEL6 installation has about 12500 symbolic links! Strange but true!

As if anyone installs RHEL6 on a shared folder...

Anyway, just wanted to reply to your pretty wild conspiracy. It's a bug, and it simply needs quite a bit of time to get it sorted.

[schisamo]

Replying to frank:

If you do

VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate 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 can verify this works with one tweak, the proper format of the setextradata command key name is actually:

VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1

Note the SHARE_NAME bit. I figured this out after digging ​through the C code! :)

[Frank Mehnert]

Replying to schisamo:

Note the SHARE_NAME bit. I figured this out after digging through the C code! :)

It was actually my intention to make people think :-P Well, sorry, actually I missed that part so thanks for the complement.

[studgeek]

This doesn't seem to be working for me with Ubuntu guest on XP host with 4.1.14.

I think I have the right extradata set:

$ VBoxManage.exe getextradata UbuntuServer2 enumerate
Key: VBoxInternal2/SharedFoldersEnableSymlinksCreate/z, Value: 1

But I get the following when trying to do links:

reesd@ubuntu2:/media/sf_z$ touch a
reesd@ubuntu2:/media/sf_z$ ln -s a b
ln: failed to create symbolic link `b': Read-only file system
reesd@ubuntu2:/media/sf_z$ ln a b
ln: failed to create hard link `b' => `a': Operation not permitted
reesd@ubuntu2:/media/sf_z$

This is on a new install of 4.1.14 with a newly created Ubuntu vm. Am I missing another trick?

Thanks, dave

Guest: Ubuntu 12.04 Server 32bit
Host: Windows XP SP3
VirtualBox: 4.1.14

[jules]

Same here. I am using 4.1.14. I put this in my fstab and mount...

pin10           /home/pin10             vboxsf  defaults        1 2

I execute this from windows powershell...

.\VBoxManage.exe setextradata BRM_7.5_V1_VM VBoxInternal2/SharedFoldersEnableSymlinksCreate/pin10 1

I verify it was added to the xml

<ExtraDataItem name="VBoxInternal2/SharedFoldersEnableSymlinksCreate/pin10" value="1"/>

Then I re-start the VM. From the command prompt.

[root /home/pin10]$ ln -s jakarta-tomcat-5.0.28/ tomcat
ln: creating symbolic link `tomcat' to `jakarta-tomcat-5.0.28/': Read-only file system

Symlinks are very important because the stuff I would host on the shared folders won't work without them. Shared folders would otherwise be an awesome feature.

[soenke]

Hey, Somehow I don't get the command to work. if I do:

# VBoxManage setextradata android VBoxInternal2/SharedFoldersEnableSymlinksCreate/android 1

I get

VBoxManage: error: Could not find a registered machine named 'android'
VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBox, interface IVirtualBox, callee nsISupports
Context: "FindMachine(Bstr(a->argv[0]).raw(), machine.asOutParam())" at line 773 of file VBoxManageMisc.cpp

The host is Windows 7, the system is ubuntu 11.10 and I need the possibility of symlinks.

the machine is called android (because I want to set up an environment for some android experiments). Is it the wrong way I pass the name in the command?

[Ben Ellis]

I too have had no luck getting virtualbox to allow me to create symlinks on the shared folder from within the guest.

Trying with a Mac OS host, Ubuntu guest (shared folder configured via the vagrant gem), ran:

VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1

with VM_NAME and SHARE_NAME replaced, verified those were written to xml, rebooted my guest, no luck.

I would love to hear of any option for creating symlinks, aside from either creating them via the host (which is a pain) or downgrading to VB 4.1.6 (rather not do that).

Needless to say, many applications rely on symlinks. Not being able to create them from the guest really limits the value of shared folders for me.

[Freddy Willemsen]

Funny thing is that everybody seems to concentrate on the symlinks. I got that part working using the setextradata SharedFoldersEnableSymlinksCreate solution. However, hard links still fail (using 4.2.2). Is there a solution for those type of links as well?

[gsp]

Version 4.2.4 r81684

In help chapter ch04s03.html symlink is claimed as working for linux/solaris guest and host. No exception mentioned.

I vote for symlink and hardlink working the same way as in networking:
a guest process reading a symlink -> /etc/passwd reads guests /etc/passwd
a host process reading a symlink -> /etc/passwd reads hosts /etc/passwd
hardlinks should work only on the same volume and the same share

For me, the setextradata hack works only if i put the absolute path for SHARE_NAME as in

VBoxManage setextradata CENTOS VBoxInternal2/SharedFoldersEnableSymlinksCreate/home/oe 1

[Nicolas Grilly]

I agree with gsp.

Making symlinks work as claimed by the documentation would be nice (when the host supports symlinks and when the guest runs Linux or Solaris).

frank wrote symlinks were disabled for security reasons, but I'm note sure to understand why. Have you an example of an attack scenario?

Having disabled symlinks is disturbing for developers using VirtualBox to run a local Linux dev server, for example using Vagrant.

Anyway, thank you for VirtualBox which is a fantastic tool.

[frickenate]

The VBoxInternal2/SharedFoldersEnableSymlinksCreate workaround does not appear to work with an Ubuntu guest running on a Windows 7 host. I don't care about the ability to create symlinks from the Windows host; what matters is that Ubuntu be able to create symlinks for its own use.

It is thus impossible to use VirtualBox shared folders to run a linux development vm box on a Windows host. What we need is the ability to host (for example) web application code on Windows, with the linux machine being able to run a web server document root from a share of that code base.

[RoelV]

Bug #11642 was made a duplicate of this. Host OS was Win7. Please update host OS to be blank (i.e. it's Linux + Windows + maybe others)

[RoelV]

When will this bug be fixed?

[Frank Mehnert]

See comment comment 13. It's quite difficult to implement a correct fix, even only for Linux hosts. Currently no ETA.

[mateodelnorte]

I am experiencing this problem as well. Windows 7 Host, Ubuntu client.

The bug makes it impossible for me to develop using a shared folder from my host, which is the only reason I'm using VBox.

Applying "setextradata [boxname] VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1" did not solve the problem, nor does running as Admin.

I would love to see this fixed.

Thanks a bunch.

[Roger]

The instructions here do work but it is confusing what all has to be restarted for them to be applied. I think you have to restart the VirtualBox application for the settings to be seen. You could just restart your whole host machine.

Replying to mateodelnorte:

I am experiencing this problem as well. Windows 7 Host, Ubuntu client.

The bug makes it impossible for me to develop using a shared folder from my host, which is the only reason I'm using VBox.

Applying "setextradata [boxname] VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1" did not solve the problem, nor does running as Admin.

I would love to see this fixed.

Thanks a bunch.

[abiliofaria]

mateodelnorte, After running "VBoxManage setextradata ...", try to restart the VirtualBox as admin. It works for me, using VirtualBox 4.2.12, Windows 7 as host and Ubuntu 12.04 as guest.

When VirtualBox was not restarted as admin, I was facing the error "ln: failed to create symbolic link '...': Protocol error".

[newbrific]

As of version 4.3.2, it is insufficient to run VirtualBox as an admin one time to allow any number of symlinks to be subsequently created during future instantiations of a guest VM that requires them. Instead, one has to run VirtualBox with administrative rights each and every time one might need this functionality. That cure is worse than the disease, so it's best to find an alternative to VirtualBox's shared folders (sigh).

P.S. Using VBoxManage with global instead of a particular VM seems to always fail, also.

[Frank Mehnert]

VirtualBox should never run as Admin as this is a security risk. The symlink problem is a Microsoft problem. There need to be proper permissions to create a symlink on a Windows host and I'm sure such permissions can be granted even to restricted Windows accounts.

[peci1]

I have done some Windows research on this bug.

If your user is of the Administrator type (rather than a Standard account), there's no way to run VB with symlinks working without the UAC prompt.

If you have a Standard user account (or if you are willing to switch your account to Standard and create a separate Admin account), the solution exists. You will, however, need admin privileges to accomplish several of the steps (not necesarrily for your user account).

1. Run the Local Security Policy (Win+R, type "secpol.msc", confirm UAC). Then navigate to "Local Policies->User Rights Assignment".
2. Find the permission called "Create symbolic links" and double-click it. Add your user to the list of objects having this permission. Or you can add the "Users" group. Log off and log on. You can check the success by running in console:

   whoami /priv
   

If you see the privilege SeCreateSymbolicLinkPrivilege enabled, you've done well.

3. Make sure your user has proper access to the shared folder on host system.
4. As mentioned here earlier, execute

   VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1
   

in a console from the C:\Program Files\VirtualBox folder. Don't forget to substitute VM_NAME with the name of your VM and SHARE_NAME with the name of the shared folder (as it appears in the VM settings).

5. You're done.

If you happen to own one of the "lesser" version of windows (e.g. 7 Home), you don't have the "secpol.msc" utility. See ​http://stackoverflow.com/questions/815472/how-do-i-grant-secreatesymboliclink-on-windows-vista-home-edition for help.

[Oded]

Hi All,

I had the same issue of unable to create symbolic link over host/guest share Windows 7 as host, Solaris as guest

I solved it by:

1. VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate 1
2. secpol.msc change the policy for create symbolic link
3. final solution was to run Oracle VM virtualbox NOT as admin (I repeat NOT as admin)

Somehow when I made whoami /priv as admin the result when create symbolic link disable BUT when I made whoami /priv on my user the result didn't contain any policy for create sybolic link

[Shad Sterling]

Same issue in VirtualBox 4.3.30 (and 4.3.28). Host: Mac OS X Yosemite 10.10.4, Guest: CentOS 7

It's working now, but this comes after the workaround in comment:12 and comment:13 didn't work on 4.3.28, I upgraded to 4.3.30 where again the workaround didn't work, I upgraded to 5.0.0 which broke shared folders entirely, downgraded back to 4.3.30 and tried again... and now it's working, and it only took half a day.

If the concern is that symlinks might sometimes have targets outside the shared folder (which could make a hostile guest able to harm a vulnerable host by making a symlink), I would expect the default to only prohibit symlinks that actually have targets outside the shared folder. Prohibiting all symlinks might be a useful option, but it's a terrible default. A better security measure would be prohibiting any access to such targets at any time, not just at symlink creation time. (Without that a vulnerable host/guest pair could have malware which creates a bad symlink from the host then hides itself in the guest.)

( The UI is terrible too; this should be set in the shared folders settings, and since the guest can't be given a more useful error the vbox UI - or maybe the guest additions - should give the user some sort of notification, so they don't have to spend an hour searching online only to find out it's the intentional default value of a hidden setting. )

[Frank Mehnert]

Replying to polyergic:

If the concern is that symlinks might sometimes have targets outside the shared folder (which could make a hostile guest able to harm a vulnerable host by making a symlink), I would expect the default to only prohibit symlinks that actually have targets outside the shared folder.

That's exactly the problem. A 100% race free implementation is very difficult and that's the reason we didn't implement this yet. There are many many other problems with a higher priority.

[Frank Mehnert]

Replying to polyergic:

It's working now, but this comes after the workaround in comment:12 and comment:13 didn't work on 4.3.28, I upgraded to 4.3.30 where again the workaround didn't work, I upgraded to 5.0.0 which broke shared folders entirely, downgraded back to 4.3.30 and tried again... and now it's working, and it only took half a day.

And you don't think that you did a mistake? We didn't change this code recently and the situation is even documented in the user manual, see section 4.3.

( The UI is terrible too; this should be set in the shared folders settings, and since the guest can't be given a more useful error the vbox UI - or maybe the guest additions - should give the user some sort of notification, so they don't have to spend an hour searching online only to find out it's the intentional default value of a hidden setting. )

I don't know what you mean by "terrible" UI. The documented VBoxManage setextradata command is only a workaround for users who know what they are doing and therefore not part of the GUI.

[Shad Sterling]

Replying to frank:

Replying to polyergic:

If the concern is that symlinks might sometimes have targets outside the shared folder (which could make a hostile guest able to harm a vulnerable host by making a symlink), I would expect the default to only prohibit symlinks that actually have targets outside the shared folder.

That's exactly the problem. A 100% race free implementation is very difficult and that's the reason we didn't implement this yet. There are many many other problems with a higher priority.

Maybe I'm missing something obvious here, but I don't see what the race would be.

[Shad Sterling]

Replying to frank:

Replying to polyergic:

It's working now, but this comes after the workaround in comment:12 and comment:13 didn't work on 4.3.28, I upgraded to 4.3.30 where again the workaround didn't work, I upgraded to 5.0.0 which broke shared folders entirely, downgraded back to 4.3.30 and tried again... and now it's working, and it only took half a day.

And you don't think that you did a mistake? We didn't change this code recently and the situation is even documented in the user manual, see section 4.3.

( The UI is terrible too; this should be set in the shared folders settings, and since the guest can't be given a more useful error the vbox UI - or maybe the guest additions - should give the user some sort of notification, so they don't have to spend an hour searching online only to find out it's the intentional default value of a hidden setting. )

I don't know what you mean by "terrible" UI. The documented VBoxManage setextradata command is only a workaround for users who know what they are doing and therefore not part of the GUI.

What I mean is that my opinion of the UI regarding symlinks in shared folders is that it's terrible. Maybe I should say UX there? When you violate the principle of least surprise that dramatically and with no feedback it doesn't occur to me to look in the manual for why that behavior is intended, because it doesn't seem possible that that behavior would be intentional. it seems like something is malfunctioning. Isn't that why this ticket exists?

[Frank Mehnert]

Again, the UI has nothing to do with symlinks. The VBoxManage setextradata command is a workaround to enable symlinks for users who know what they are doing (ie they trust their guest). Symlinks are currently disabled for security reasons because the host should not trust the guest. The ticket is there because a user reported the lack of symlinks in shared folders and requested security-proved implementation, that's all. What do you want, a message box popping up "sorry, symlinks are currently not suppoted by VirtualBox" when the guest tries to create a symlink? -EROFS is an appropriate error code for the guest in such cases. As mentioned above, the shared folder implementation is far away from being complete. Code contributions are welcome.

Regarding the technical difficulty: The guest is able to do things in parallel. It's able to create/change symlinks (if enabled) and to open the file the symlink points to shortly after the symlink was changed/created. The point is that a file name can contain of multiple parts (foo/buzz/bar) and each of the component can be a symlink. So to check if foo/buzz/bar points to a file outside of the shared folder, the complete path must be converted to a symlink-free notation atomically and this is quite difficult in SMP environments, at least with older versions of Linux. Never Linux kernels provide the nesessary functionality but still every used function in the shared folders host service needs to be adapted and that's a lot of work.

[Shad Sterling]

Replying to frank:

Again, the UI has nothing to do with symlinks. The VBoxManage setextradata command is a workaround to enable symlinks for users who know what they are doing (ie they trust their guest). Symlinks are currently disabled for security reasons because the host should not trust the guest. The ticket is there because a user reported the lack of symlinks in shared folders and requested security-proved implementation, that's all. What do you want, a message box popping up "sorry, symlinks are currently not suppoted by VirtualBox" when the guest tries to create a symlink? -EROFS is an appropriate error code for the guest in such cases. As mentioned above, the shared folder implementation is far away from being complete. Code contributions are welcome.

Ok, so call it UX then. As a user, my experience with symlinks in shared folders was not a good one. A message box explaining the situation would be an improvement. It probably shouldn't just say they're not supported, it should say why and link to more information that includes how to enable them - perhaps the section 4.3 of the manual. (If all I had found was that they're not supported, I might have wasted even more time looking for a replacement for VirtualBox!)

Regarding the technical difficulty: The guest is able to do things in parallel. It's able to create/change symlinks (if enabled) and to open the file the symlink points to shortly after the symlink was changed/created. The point is that a file name can contain of multiple parts (foo/buzz/bar) and each of the component can be a symlink. So to check if foo/buzz/bar points to a file outside of the shared folder, the complete path must be converted to a symlink-free notation atomically and this is quite difficult in SMP environments, at least with older versions of Linux. Never Linux kernels provide the nesessary functionality but still every used function in the shared folders host service needs to be adapted and that's a lot of work.

I think I see. It's also that you can't just resolve the link target in the guest, because the host service has to open by path, which might have changed to be a symlink. I would think that when the file is open on the host fstat could at least show weather it became a symlink. But even if that would work, it's not trivial to implement.

Can you give links directly to the relevant portions of the code?

[oobles]

I've been looking through documentation and defects trying to find out if creating a hardlink on a shared folder is supported. I've upgraded to 5.0.2 and also tried using the VBoxManage setextradata command. However, the documentation only talks about sym links. Hardlinks are not discussed directly.

I'm using a docker machine (TinyCore linux) on OSX. I can confirm creating sym links are fine.

On a shared folder in the virtual machine the following works:

$ touch test

$ ln -s test test-symlink

However the following command doesn't:

$ ln test test-hardlink

ln: test-hardlink: Operation not permitted

Is this is expected behaviour?

[nark]

I encountered this issue too, I have a C++ project which compile in msvc, cygwin and linux/mac, it will create symbol links in compiling, I compile the source code in guest linux in shared folder, it failed for this issue!

[3vi1J]

I'm really surprised to find this bug existed... and to find it's been open for four years.

I ran into this while trying to compile UnrealEngine in an Ubuntu 14.04 VM. The Setup.sh tries to do some ln -s commands, and fails/aborts because the file system is 'read only'.

If I do the ln -s manually in the same directory I get the same failure. However, I can use mkdir or touch from that directory to create new files/directories with no problems.

Before searching and finding this bug, I tried using automount to mount the file systems, assuming I had done something wrong. But, whether the directory is automounted or mounted manually the failure persists.

[robby]

In my case I have been successful creating the directory structure I want on a virtualbox virtual disk, then use something like 'rsync -a guest:dir host_shared_dir' from the host to copy that structure to the shared drive. Once the link is created the guest will see it and use it; seems to me that this approach would or could solve all of the cases above, including where scripts under development create the links later on the shared folder.

As noted in the comments, you can create the links on the host. They will dangle there if the reference does not exist on the host, but they will work on the guest.

You can also apparently vboxedit a flag if you really can't think of any other way and you really need to work on a shared folder and really from the guest. The guest will then have access to the entire (according to permissions) host filesystem, so no longer safe for untrusted code etc.

It isn't a bug, it is a complicated problem in a system that fundamentally needs to protect the host from the guest, in particular as the product is targeted at 'consumers'. Yes it would be nice if there were a more obvious error message, but I found this page without any trouble using the information provided.

I don't work for Oracle or VirtualBox, but I just ran into this today and the developers' comments seem clear to me.

[gil]

Replying to klaus:

I thought I explained it clearly - the previous VirtualBox shared folders behavior related to symlinks was simply wrong, and this isn't primarily due to the host OS or its filesystem capabilities. If you happened to have no problems with symlinks consider yourself lucky.

I agree with rwstandridge. For example, if I create a symlink on the host sysem (in this case, it's dangling):

590 $ uname -a Darwin ....local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 591 $ pwd /Users/paulgilm/work/Shared/tmp 592 $ ls -l foomotd ls: foomotd: No such file or directory 593 $ ln -s /etc/motd foomotd 594 $ ls -l foomotd lrwxr-xr-x 1 ... staff 9 Feb 6 17:40 foomotd -> /etc/motd 595 $ cat foomotd cat: foomotd: No such file or directory

But on the Linux guest, it resolves in the guest namespace:

545 $ ls -l foomotd lrwxrwx--- 1 root vboxsf 9 Feb 6 17:29 foomotd -> /etc/motd 546 $ 546 $ cat foomotd

.-. ... - LGB/dew

This agrees with NFS practice; I see no benefit to changing that much.

Simply, if the symlink is created on the guest system, the behavior should be the same as if it were created on the host. The guest should never follow symlinks in shared folders to filesystems not mounted on the guest; it should follow them if their paths resolve to filesystems mounted on the guest.

-- gil

[szx]

I'm facing the same problem with VirtualBox 5.0.20 running Ubuntu 14.04 guest on Ubuntu 16.04 host. The shared folder is located on an ext4 partition and is mounted as read-write. But any symlink creation fails with a "Read-only file system" error.

[sorin]

Any plans to fix-this-fix? Now the mounted shared folders are broken as symlinks functionality is used extensively by virtualenv tools. I really hate the fact that I need to run this command to fix the shares:

VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME 1

If that new behaviour is there to remain (even if other virtualisation platforms do not have it) at least we need a new checkbox in the UI that would enable the symlinks.

[Michael Thayer]

Added aplatypus to the CC list.

[Paul W Panish]

I'm posting a reply to receive notifications when this defect is updated. I have the same problem using VirtualBox v5.1.14 on a Mac host running ElCapitan. I'm trying to backup an open source project from a shared directory on the host. My project uses automake, which requires symbolic links to function properly. Unlike the comment above from sarin, I've tried the VBoxManage... solution noted in this post and elsewhere with no success.

[rom1desboa]

No luck either with VirtualBox 5.1.16 running on OSX 10.9.5 with Ubuntu 16.04.2 as guest, even with the SharedFoldersEnableSymlinksCreate set to 1. I get the same "read only" file system error on attempting to create a symlink from the guest on a shared folder.

It's unclear to me at this stage what combinations of host/guest OS work. Has anyone got this working on OSX as host and Linux as guest?

[Worley]

I got this combination to work, including creating symbolic links:

VirtualBox: Version 5.1.22 r115126 (Qt5.6.2)

VM guest with the guest tools: /usr/bin/VBoxClient reports version 5.0.14r1051267

Guest OS: Oracle Linux / Red Hat Enterprise Linux Server release 7.3 (Maipo) / Linux xxx 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 03:54:13 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

Host OS: OS X El Capitan Version 10.11.6

However, the guest not to be able to set the modification times of symbolic links. This operation is done by "cp -a" and "rsync", among other commands. But it doesn't seem to cause any problems in practice.

[sorin]

Maybe someone can remove me from being CC on this issue. Somehow I see not option to do this myself, for this issue of the for the entire Tracker.

[Wayne Sallee]

To remove yourself from CC, all you have to do is, , , , , , , , , , , , ,

LOL it's a zombie You can't kill it! :-)

That should be simple, but I don't see it either.

It looks like this ticket is closed and that's the reason you can't remove yourself from it. It's a zombie. It won't die. :-)

Wayne Sallee Wayne@… ​http://www.WayneSallee.com

[Will]

On a point of clarification; to correct an earlier rant about how things "are not for free" ...

Symbolic link facility is part of the product. It is not a "new" thing, it was reportedly working and has stopped working. It is documented to work.

This bug is requesting correction of a flaw in VirtualBox.

It is not a "zombie" it is a vital piece of a working virtual machine environment.

[fatz]

Strange "fix"... more of a nuisance in my view. I'd add a checkbox to the UI and tell the user about the risks instead of leaving that open for 6 years. But OK this is not my project. It's your joice to make a good thing bad.....

I'm currently trying out VBox 5.0.40 on a Ubuntu host with a Debian guest and could not get the thing to let me create symbolic links in the shared folder with the aformentioned fix. I could not find any xml entry changed by VBoxManage. I ended up with editing ~/.config/VirtualBox/VirtualBox.xml (while no VBox related progs running of course) placing the line

<ExtraDataItem name="VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARE_NAME" value="1"/>

as the last entry in the ExtraData section. This might be a bad hack but at least it works for me. Hope This helps somebody.....

[Frank Batschulat (Oracle)]

One problem with the current behavior is certainly the error returned by vboxsf/vboxfs in the guest. On Solaris it is EROFS, on Linux this is EPERM. Of course, both are bogus. We neither deal with a read-only file system nor does the user lack any permissions or privileges. Instead we just do not support creating symlinks from within the guests inside the shared folder. ENOTSUP it should have been which would also have prevented a lot of unnecessary questions as it had made very clear where the problem lies rather then EROFS/EPERM. That at least should be fixed as long as we do not want to support symlinks/hardlinks this way from inside the guest.

[Bobi]

any updates? still not working on my side using vbox 6.1 and I already set the symlink permission in windows 10

see below commands:

osboxes@osboxes:/media/sf_MyLearning$ ln -s ~/Dev/ Test ln: failed to create symbolic link 'Test/Dev': Operation not permitted osboxes@osboxes:/media/sf_MyLearning$ sudo ln -s ~/Dev/ Test [sudo] password for osboxes: ln: failed to create symbolic link 'Test/Dev': Operation not permitted