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.