VirtualBox

Ticket #10085 (new defect)

Opened 2 years ago

Last modified 5 months ago

making a symlink fails on a shared folder with EROFS

Reported by: win32asm Owned by:
Priority: major Component: shared folders
Version: VirtualBox 4.1.8 Keywords: symlink, shared folders
Cc: Guest type: Linux
Host type: all

Description (last modified by klaus) (diff)

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

Change History

comment:1 Changed 2 years ago by rwstandridge

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.

comment:2 Changed 2 years ago by 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').

comment:3 Changed 2 years ago by oleKanin

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

comment:4 Changed 2 years ago by Technologov

+1

comment:5 Changed 2 years ago by 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:

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

comment:6 Changed 2 years ago by 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.

comment:7 follow-up: ↓ 8 Changed 2 years ago by klaus

  • Description modified (diff)

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.

comment:8 in reply to: ↑ 7 Changed 2 years ago by rwstandridge

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?

comment:9 Changed 2 years ago by 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.

comment:10 follow-up: ↓ 13 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by 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.

comment:12 follow-up: ↓ 14 Changed 2 years ago by frank

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

Version 0, edited 2 years ago by frank (next)

comment:13 in reply to: ↑ 10 Changed 2 years ago by klaus

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.

comment:14 in reply to: ↑ 12 ; follow-up: ↓ 15 Changed 2 years ago by 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! :)

comment:15 in reply to: ↑ 14 Changed 2 years ago by frank

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.

comment:16 Changed 2 years ago by 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
Last edited 2 years ago by studgeek (previous) (diff)

comment:17 Changed 2 years ago by 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.

comment:18 Changed 22 months ago by 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?

comment:19 Changed 19 months ago by benissimo

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.

comment:20 Changed 18 months ago by FreddyW

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?

comment:21 Changed 16 months ago by 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

comment:22 Changed 16 months ago by ngrilly

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.

comment:23 Changed 15 months ago by 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.

comment:24 Changed 13 months ago by 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)

comment:25 Changed 13 months ago by RoelV

When will this bug be fixed?

comment:26 Changed 13 months ago by frank

  • Host type changed from Linux to all

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

comment:27 follow-up: ↓ 28 Changed 11 months ago by 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.

comment:28 in reply to: ↑ 27 Changed 11 months ago by rwstandridge

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.

comment:29 Changed 10 months ago by 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".

comment:30 Changed 5 months ago by 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.

comment:31 Changed 5 months ago by frank

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use