vboxvfs lacks support for host side symbolic / hard links

[Jan]

When mounting a file system via the shared folder feature between a Linux host and a Linux guest, symbolic links in the host system appear as regular files/directories in the guest.

[Bernhard M.]

I retested this issue and it still holds true for VirtualBox 2.1.4. Additionally, I found that both creating symlinks and creating hard-links from the guest on vboxsf fail with "Operation not permitted". Also link count is always "1" on all entries. The User-Mode-Linux equivalent (hostfs) does not suffer such limitations, so it is somehow doable.

[Brett Williams]

I see this is marked as minor -- are there any plans to support this?

I have set up backuppc running on my guest and was going to point it to a shared folder on the host, but backuppc relies on hardlinks for its data storage to be efficient. This doesn't work since hard linking is not supported?

[Yann]

I just ran into the same issue over here. Does Oracle plan to support this in the future?

[Lucian]

Lack of symlink support makes sharing things harder than it should be (since it requires copying).

I would very much like it if support for symlinks could be added.

[Yehoshua Shoshan]

Add my voice here. Soft links are important on Linux system. Using (/etc/fstab) # ++++++++++++++++++++++++++++++++++++++++ altera /opt/altera vboxsf defaults 0 0 # ++++++++++++++++++++++++++++++++++++++++

I get the following error: [yesh@vdtf21 install]$ cd /opt/altera/install/ [yesh@vdtf21 install]$ ln -s ../tars/90_quartus_linux.tar . ln: creating symbolic link `./90_quartus_linux.tar': Operation not permitted [yesh@vdtf21 install]$

vBox: 3.0.2 r49928 (linux 64 bits)

host: Linux rdt02 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

Guest: Linux vdtf21 2.6.29.6-213.fc11.i686.PAE #1 SMP Tue Jul 7 20:59:29 EDT 2009 i686 i686 i386 GNU/Linux

Yehoshua

[KuniGunther]

Please update the version number for this ticket to VirtualBox 3.0.4 as this is not fixed.

The problem is not only that symbolic links on the host system are displayed as regular files on the guest system, the more important defect is, that symbolic links cannot be created and changed on the guest system.

The lack of symbolic support makes shared folders quite useless for Linux guests as they are commonly used by all kinds of programms. Thus, if not fixing this is basically the same as dropping shared folder support for linux guests - actually, the latter would be more honest.

This is by no means a "minor" issue. It is a prerequisite for shared folders to be used on Linux guests.

[Sander van Leeuwen]

We'll consider dropping shared folder support just to please you next time. I'm sure many others will appreciate this. :)

[wader]

How do i add as CC? just reply?

[Frank Mehnert]

Adding a comment here is enough to receive all further comments of this ticket.

[LoOoD]

Same goes for version 3.0.6. Please add support for symbolic links and increase priority.

[Frank Mehnert]

Contributions are welcome.

[John Whitley]

commenting to track this ticket.

[smith.winston.101]

Running VirtualBox 3.0.6 with guest Ubuntu 9.04 64-bit on a Mac OS X 10.6.1 Snow Leopard host:

strace ln -s foo bar

Gives the following (edited to remove irrelavent stuff):

stat("bar", 0x7fffa0fdb250)             = -1 ENOENT (No such file or directory)
symlink("foo", "bar")                   = -1 EPERM (Operation not permitted)
...
write(2, "ln: "..., 4)                          = 4
write(2, "creating symbolic link `bar'"..., 28) = 28
write(2, ": Operation not permitted"..., 25)    = 25
write(2, "\n"..., 1)                            = 1

In the meantime, running dtrace -p <pid> on the appropriate VirtualBoxVM process on the Mac side shows no trace of the symlink call being attempted against the host filesystem. Presumably, it's just not implemented.

Next step is to look at the sources ...

[John Whitley]

Frank's note implied this, but let's just be perfectly clear: symbolic link support is not yet implemented in the vboxsf filesystem. For folks who want to check out the current state of the guest additions linux module, have a look at the files at following path in the VirtualBox source tree:

src/VBox/Additions/linux/sharedfolders/

Specifically, dirops.c should define the symlink, readlink, and follow_link members of struct inode_operations (see bottom of that file, and linux/fs.h in the kernel headers). I started looking at this the other day, and have cloned the public SVN repo to github at: ​git://github.com/jwhitley/VirtualBox.git.

VirtualBox devs: pointers and/or documentation links that would speed up my understanding the guest additions to VirtualBox plumbing would be greatly appreciated. Thoughts or comments on what to look at on the virtualbox host side towards implementing the above functions would be especially valuable.

[Frank Mehnert]

There is no other documentation for the shared folders service than the source code. All shared folders operations will be forwarded to the host where they will be handled in src/VBox/HostServices/SharedFolders/service.cpp, see the function svcCall(). The corresponding handlers are implemented in vbsf.cpp in the same directory.

[antoinea]

Add my voice to this one. I'm unable to develop in the Ubuntu VM (host WinVista) because the build process fails due to lack of symlink support. This is a huge problem for us developers. I don't see any workaround right now.

[John Whitley]

antoinea: The workaround is to not use shared folders for processes that require symlink support. For builds, what I've been doing is to synchronize code between the dev system (host) and the guest VM. Tools such as rsync can work for this, but I prefer to use decentralized version control, such as git, bzr, etc.

[Technologov]

Added myself as CC on this issue.

-Technologov

[cary co]

add myself as CC. maybe using NFS or SSHFS is a workaround.

[Giovanni Toraldo (gionn)]

Using nfsd on host or client is a good workaround, if speed isn't a problem.

Even with gigabit virtual card on a host-only network, I get ~20 MB/s; with shared folders the speed is near host (~45 MB/s).

SSHFS is an alternative but it isn't very fast due to it's limitations.

[smith.winston.101]

SSHFS may work for you, but it also has [different] issues with symbolic links. If you have symbolic links with absolute references in them, then it fails. It does have a mechanism for attempting to remap prefixes, but I couldn't get it to work in the particular situation I had. Basically, if the "server" system has symbolic link to say /home/foobar/.profile, then if you mount /home as /mnt in the client, the symlink will still refer to /home/foobar/.profile, it needs to be remapped to read /mnt/foobar/.profile.

[Johan]

In the Changelog for VirtualBox 3.1.2 (released 2009-12-17), we can read "Shared folders: fixed resolving of symlink target (bug #5631)" At first i tought this issue was totally fixed, but seeing this bug is still unresolved, i suppose it's not!

[Johan]

OK, The changelog said, "fixed *resolving*", not creation.

[kblcuk]

Confirming this problem on OS X host and Ubuntu guest. In previous release I could use linked files and folders in my shared folders (they weren't seen as links, though), however as of 3.1.2 r56127 I can't cd to linked folders anymore. Files still work, though. Hmm, that sounds like a regression again.

[kblcuk]

Replying to kblcuk: "Previous release" in my case would be 3.0.8

[Frank Mehnert]

kblcuk, you are right, and this specific issue (host symlinks couldn't be followed on the guest) will be fixed in the next maintenace release of VBox.

[paleo]

Confirming I still have this problem on VBox 3.1.2 with MacOSX Host and Ubuntu Guest... I hope this bug will be solved soon

[Iraê]

At work I use host Mac OS X 10.5.8, Linux CentOS guest and Virtualbox 3.0.12 r54655. Symbolic links created on the host file system works well on the guest file system via vboxsf mount. I rely on symbolic links for my work, so I won't update yet as everything is fine.

At home however, it doesn't work. There I use Mac OS X 10.6.2, same CentOS host. I was using Virtualbox 3.x (can't remember minor version) and it won't work. Updated to Virtualbox 3.1.2 and still won't work.

Mas OS X 10.6.x had some updates to the HFS+ file system and the filesystem API, so I thought this might be useful info. Tough Apple documentation may be more complete, I've read about the changes here: ​http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/7

[johno12345]

I have a feeling this may be a bug with a purpose, you see filesystems such as NTFS(before vista) and FAT/16/32 don't support symlinks.

However it would be really nice to see symlink support added to shared folders as its just ground a project i'm working on to a major standstill! DOH!

[ximo]

This is a big show stopper for me as well. Due to this bug I'm not able to get the development environment I was aiming for (OS X host + Linux guest), forcing me to either look for alternatives like SAMBA (more complexity, worse security) or give up on VirtualBox and try competing products like VMWare, which I know supports this. I can't contribute with much, but consider this a vote for raising the priority of this issue.

[paleo]

I'm another user who needs to create a development environment with MacOSX as host and Linux as guest... Just ANOTHER VOTE to raise proprity of this issue! Thanx

[kblcuk]

Replying to kblcuk:

Replying to kblcuk: "Previous release" in my case would be 3.0.8

The new release 3.1.4 fixed the regression problem, woohoo! However, linking in shared folders on Guest side in Linux still doesn't work. But for me, I can work around that by creating links on the Mac side (luckily, I need only relative links from shared folder to shared folder.

Hope this one will be fixed soon!

[Craig Miller]

Please add me to this ticket. I see the same problem with MacOS X host (10.6.2) and Ubuntu Linux Guest using VirtualBox 3.1.6 r59351.

[levity]

Commenting in order to be added to this ticket and to raise its importance. I can work around this issue for now (Snow Leopard host, Ubuntu guest), but it is a pretty curious omission.

[dma_k]

I vote for this feature. In particular, it would be nice to have symlinks/hardlinks supported by vboxsf, if host filesystem supports them (e.g. NTFS supports hardlinks in WinXP and later; and symlinks from Vista and later).

[excsm]

Adding my vote to push up the priority of this ticket. This is also a show stopper for me. Will have to use vmware until this is fixed.

[Klaus Espenlaub]

Just a suggestion: why not find someone who implements the feature? It's quite low priority for the dev team as there is no customer demand whatsoever. Until this changes I don't see much hope for your votes. Don't get me wrong, we are willing to help whoever is seriously working on this feature to get it correctly integrated.

[Dwight Schauer]

As a workaround one can use posixovl (posix overlay) on the shared folder. If one does not use the folder on the host, then only on the guest, but if in both places, then one must use posixovl in both places. Kind of a pain, but it seems to work.

​http://sourceforge.net/projects/posixovl/ ​http://www.goblinx.com.br/en/?page_id=106

​http://packages.debian.org/sid/fuse-posixovl ​http://aur.archlinux.org/packages.php?ID=26106

Well, doing in on the host implies a *nix host. I use posixovl in an Arch Linux guest on Windows XP and it works quite well. I then started using an Arch Linux guest on Arch Linux and soon found out that symlinks were not working. Seems wrong to have to use a posix overlay on a Linux filesystem shared between two Linux hosts.

[Dwight Schauer]

Well, the posixovl workaround does not perform well. Copying to the non overlayed directory from within a virtualbox session I get 100-300 MB/s Copying to the overlayed directory from within a virtualbox session I get 25-40 MB/s

I "almost" agree with KuniGunther, in that providing host <=> guest filesharing on Linux without providing symlink capabilities is roughly the same as not providing host <=> guest filesharing at all.

When host <=> guest filesharing on Linux VirtualBox is basically the same as a bind mount in terms of performance and capabilities, then this problem will be solved.

In other words, what is needed is fully transparent host <=> guest filesystem support (explicity mapped of course).

[Robin Edgar]

Wow, after spending a few hours trying all the rsync options and looking up Google for why rsync kept throwing up

rsync: symlink "/dir/link" -> "/dir/name" failed: Operation not permitted (1)

errors I discover *this* How can we live without symbolic links?!

Back to the drawing board then...

[kyleb]

I'll add my vote to request full support for symlinks. I have a linux guest on an OS X host and can't do any development work under linux because symlinks are used so extensively in source trees.

I have tried a workaround using nfs. I had to create a second network interface in host-only mode. Now I have DNS issues with the two interfaces that I have not been able to fully resolve (due apparently to another ongoing vbox issue which I'm addressing in another list).

Is symlink support a hard thing to add?

[mankiko]

Not having this is tough, really limits the usefulness of vboxvfs on linux. Count my vote too.

[kami911]

Also affects me, please fix it. 3.2.6

[gaarby]

Hello

This issue is very sensitive for me. I use shared folder for backup and so I have to create a lot of link (from shared folder to shared folder), doing copy is not a real workaround for me You can add my vote and please change status to major

Like kyleb I have to use NFS but this create other problems (DNS, moving virtual machine to other host...) So a real shared folder that support link will be very nice.

[Brian Campbell]

I've been working on symlink support in some spare time over the last week or so, and I'll attach what I've done so far as a patch shortly. Note that this is a work in progress: it's just support for reading links so far, it's only been tried with Linux host and guest (though it should work for other posix systems), and there's no way to get the old behaviour back when you need it. Also, I don't intend to do anything about hard links. The patch is against 3.2.6 OSE.

[Brian Campbell]

Symlink reading patch for Linux; made against 3.2.6 OSE.

[Brian Campbell]

As before, but with symlink creation too.

[Junqian Gordon Xu]

Vbox version 4.0.0 Host MacOS 10.6.5 Guest Debian Squeeze

This should be at least a Major priority.

[Frank Mehnert]

Did you actually check VBox 4.0 (with VBox 4.0 Guest Additions)? I didn't test Mac OS X hosts but as long as the file system supports it the guest should be able to use symbolic links.

[Junqian Gordon Xu]

I see it's listed as fixed in 4.0.0. But so far I've not been able to verify the Guest Additions are working. Here are what I did:

apt-get remove (3.2.10-dfsg-1):

virtualbox-ose-guest-dkms virtualbox-ose-guest-utils virtualbox-ose-guest-x11

run VBoxLinuxAdditions.run

kernel module compiled and setup finished without a problem.

Boot-up log shows a one line message (likely bogus): starting virtualbox guest additions (but without version and release number). I suspect it's bogus because during shut-down, stopping virtualbox guest additions always fails.

There maybe some set-up issue to start v4.0.0 virtualbox guest additions. I'm waiting for 4.0.0 to be properly packaged by Debian.

Replying to frank:

Did you actually check VBox 4.0 (with VBox 4.0 Guest Additions)? I didn't test Mac OS X hosts but as long as the file system supports it the guest should be able to use symbolic links.

[Jon Kaczynski]

I just upgraded from 3.2 to 4.0 because I thought this bug was fixed. There seems to be one-way support, now. Symlinks on my linux host show up as symlinks on my linux guest, but I cannot create symlinks in my shared folders, on the guest.

host: Ubuntu 10.10<br/> guest Ubuntu 10.04

I have virtualbox 4.0 with guest additions installed (Devices | Install Guest Additions ...; sudo reboot; cd /media; sudo mkdir -p cdrom; sudo mount /dev/cdrom /media/cdrom; sh /media/cdrom/VBoxLinuxAdditions.run; sudo reboot).

I also have the ​Oracle VM VirtualBox Extension Pack installed.

[Jon Kaczynski]

Sorry, I submitted instead of previewed there.

I just upgraded from 3.2 to 4.0 because I thought this bug was fixed. There seems to be one-way support, now. Symlinks on my linux host show up as symlinks on my linux guest, but I cannot create symlinks in my shared folders, on the guest.

The ​ChangeLog lists "Linux Additions: Shared Folders now support symbolic links (bug #818)" under items fixed.

host: Ubuntu 10.10
guest Ubuntu 10.04

I have virtualbox 4.0 with guest additions installed (Devices | Install Guest Additions ...; sudo reboot; cd /media; sudo mkdir -p cdrom; sudo mount /dev/cdrom /media/cdrom; sh /media/cdrom/VBoxLinuxAdditions.run; sudo reboot).

I also have the ​Oracle VM VirtualBox Extension Pack installed.

cd /path/to/shared/folder
ln -s foo bar
ln: creating symbolic link `bar': Protocol error

Did I miss a step? Is this still an issue?

[Brian Campbell]

Replying to jmkacz:

cd /path/to/shared/folder
ln -s foo bar
ln: creating symbolic link `bar': Protocol error

Did I miss a step? Is this still an issue?

This works for me with a debian testing guest on an Ubuntu 10.04 host. From the error I suspect that some part of VirtualBox on your system is stuck at the old version. Try "dmesg | grep vbox" on both the guest and host to find out which version of the kernel modules you're using and you can get the version of the front end of VirtualBox from the Help menu.

[Jon Kaczynski]

$ dmesg | grep vbox
[ 10.754166] vboxguest: major 0, IRQ 20, I/O port d020, MMIO at 00000000f0400000 (size 0x400000)
[ 10.768861] vboxguest: Successfully loaded version 4.0.0 (interface 0x00010004)
[ 13.520619] vboxsf: Successfully loaded version 4.0.0 (interface 0x00010004)

For reference, I have this entry in my /etc/fstab:
code /mnt/vbox_code vboxsf defaults,uid=1000,gid=1000 0 0

Are there any changes that need to be made to the image when upgrading virtualbox from 3.2 to 4.0?

[Jon Kaczynski]

The above dmesg command was run on the guest. Here it is run on the host:

$ dmesg | grep vbox
[ 48.535107] vboxdrv: Found 8 processor cores.
[ 48.536246] vboxdrv: fAsync=0 offMin=0xf3 offMax=0x1d3dc
[ 48.536299] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[ 48.536301] vboxdrv: Successfully loaded version 4.0.0 (interface 0x00160000).
[ 425.306069] device vboxnet0 entered promiscuous mode
[ 434.953536] vboxnet0: no IPv6 routers present
[ 615.966522] device vboxnet0 left promiscuous mode
[ 804.448840] device vboxnet0 entered promiscuous mode

[Junqian Gordon Xu]

I can verify the one-way only support. host: MacOS 10.6.5, guest: Debian Squeeze.

dmesg | grep vbox [ 4.533073] vboxguest: major 0, IRQ 20, I/O port d020, MMIO at 00000000f0400000 (size 0x400000) [ 4.533075] vboxguest: Successfully loaded version 4.0.0 (interface 0x00010004) [ 44.874351] vboxsf: Successfully loaded version 4.0.0 (interface 0x00010004) [ 57.233037] [drm] Initialized vboxvideo 1.0.0 20090303 for 0000:00:02.0 on minor 0

I have similar /etc/fstab entry as jmkacz

Replying to jmkacz:

There seems to be one-way support, now. Symlinks on my linux host show up as symlinks on my linux guest, but I cannot create symlinks in my shared folders, on the guest.

[Brian Campbell]

Thanks for the details. Is at least one of the host and guest running in 64bit mode? If so, I think it's a bug where the sizes of some data structures are different between the host and the guest. Changeset 33994 appears to have improved this for some parts of the shared folders code, but might have made things worse for symlink. Unfortunately I can't test this with the computer I have to hand (it'll be a week or so before I can), but I could try and make a patch anyway if you'd like.

[Jon Kaczynski]

Ah, yes. Sorry I left that out.
host: Ubuntu 10.10 (64-bit)
guest Ubuntu 10.04 (32-bit)

[Junqian Gordon Xu]

host: MacOS 10.6.5 (64-bit) guest: Debian Squeeze (64-bit)

[Brian Campbell]

Patch to (hopefully) fix problem with symlink on 64bit hosts for 4.0.0

[adam]

If you guys want me to reiterate this thread then let me know! I've not managed to get symlinks on guest working yet. They do work on host, just as you mention above. I also upgraded successfully from 3.2 to 4 using your instructions above, thanks. I don't have the '/mnt/vbox_code vboxsf defaults,uid=1000,gid=1000 0 0' entry in /etc/fstab, tried adding it but produced error on reboot.

Where can I find the patch you talk of bacam?

I also have Mac OS 10.6.5 64-bit but Ubuntu 10.10 on guest

cheers

[adam]

btw, this is my /etc/fstab entry for my shared folder:

srv_ubuntu /srv_ubuntu vboxsf defaults,uid=1000,gid=1000 0 0

[Brian Campbell]

The patch is the last one I added to this bug, ​http://www.virtualbox.org/attachment/ticket/818/symlink-fix-4.0.0.patch. I'm fairly certain that it will sort out the problem, especially as someone implementing support for solaris guests proposed a similar patch on the mailing list.

[Technologov]

Although I did not test it, I hope it will be included in v4.0.2 (two people said it works for them)

-Technologov

[Frank Mehnert]

Thanks for the patch again Brian! Applied a similar fix to SVN and verified that it works.

[Jon Kaczynski]

Thank you so much for the patch. I upgraded to 4.0.2 and it is working beautifully, so far.

[kiran_th]

I upgraded to 4.0.02 for hard links support. Unfortunately, looks like 4.0.2 only supports soft links and does not support hard links :(. There are apps like mutt/procmail which use link based locking and vboxsf is lacking/annoying. Will hardlinks get supported?

[Peter van Dijk]

In 4.0.0, creating symlinks gave me a protocol error. In 4.0.2, symlinks 'succeed' but the result is useless:

vagrant@vagrantup:/vagrant$ mkdir symlinktest
vagrant@vagrantup:/vagrant$ cd symlinktest/
vagrant@vagrantup:/vagrant/symlinktest$ echo test > x
vagrant@vagrantup:/vagrant/symlinktest$ ln -s x y
vagrant@vagrantup:/vagrant/symlinktest$ ls -ld x y
-rw-r--r-- 1 vagrant vagrant   5 2011-02-16 05:31 x
drwxr-xr-x 1 vagrant vagrant 408 2011-02-16 05:31 y
vagrant@vagrantup:/vagrant/symlinktest$ rm y
rm: cannot remove `y': Is a directory
vagrant@vagrantup:/vagrant/symlinktest$ rmdir y
rmdir: failed to remove `y': Not a directory
vagrant@vagrantup:/vagrant/symlinktest$ cat y
test

This issue is not 100% reproducible; sometimes the symlink works just fine. On the outside, I always see 'y' being a symlink, even when the inside view is broken like this.

My host is VBox 4.0.2 on OS X 10.6; guest is the lucid64 image from the Vagrant project. Guest extensions appear to be up to date:

vagrant@vagrantup:/vagrant$ dmesg | grep vboxsf
[   14.823386] vboxsf: Successfully loaded version 4.0.2 (interface 0x00010004)

[Jos Backus]

Replying to Habbie:

This issue is not 100% reproducible; sometimes the symlink works just fine. On the outside, I always see 'y' being a symlink, even when the inside view is broken like this.

Fwiw, I ran this in a loop a few hundred times and it works here; CentOS 5.5 guest, VB 4.0.2 on a very recent Funtoo host, both 32-bit.

[Jos Backus]

bacam,

Any update on adding vboxsf support for link(2)? Thanks.

[Brian Campbell]

Replying to josb:

Any update on adding vboxsf support for link(2)? Thanks.

I'm not intending to do anything about link, although implementing it shouldn't be that hard. The difficult bit is presenting linked files to the guest system: they really ought to have the same inode number, but get separate ones. Note that this happens with existing hard links on the filesystem anyway, regardless of whether link is implemented.

Personally, I wasn't too interested in hard links; many filesystems don't bother with them anyway.

[Jos Backus]

Thanks for the update, Brian.

Just so I understand: are you saying that vboxsf does not use the inode numbers presented by the underlying filesystem but generates its own inode numbers and presents those to the guest?

AfaIk, hard links are supported by many UNIX/Linux filesystems. I think they are part of some POSIX spec, but I could be wrong.

Some tools at $WORK use hard links, which is why I'm trying to implement link(2) . I'm trying to avoid having to use NFS mounts over.

[Jos Backus]

Over loopback, sorry.

[krislie]

Just upgraded from 4.0.2 to 4.0.4. and installed the guest additions. Symlinks were working fine before the upgrade but they don't work with the new version.

[Jos Backus]

I see. Files with the same inode number in the host filesystem have different inode numbers in vboxsf. So even if link(2) was implemented it would be somewhat useless because the files wouldn't actually show up as linked. While I'm confident I could implement link(2), this restriction renders it useless for our purposes. And implementing the latter is beyond my current abilities.

Fwiw, ​http://en.wikipedia.org/wiki/Hard_link (can't find a link to the official POSIX spec, sorry) has this to say about hard links:

"On POSIX-compliant and partially POSIX-compliant operating systems, such as all Unix-like systems, additional hard links to existing files are created with the link() system call, or the ln and link command-line utilities. The stat command can reveal how many hard links point to a given file. The link count is also included in the output of ls -l."

So back to using NFS it is. Bummer.

[Lester Ingber]

The statement that "Files with the same inode number in the host filesystem have different inode numbers in vboxsf." seems to explain my problem, but just to be sure here it is:

Under Win7 Ultimate x64, I run Cygwin and also VirtualBox/Ubuntu 10.10 x64. I also have my remote VPS for my domain elsewhere running under Ubuntu 10.10 x64.

When I rsync directories containing regular as well as symlink dirs and files between Cygwin and the remote VPS, everything is properly archived.

However, I cannot rsync symbolic dirs or files between (either direction) Cygwin and VirtualBox/Ubuntu.

I still do not quite understand why I have no problems with my remote VPS, but have these problems with my "local" VB. Is this because of the inode condition above, which seems to only apply to my local VB?

Thanks.

Lester

[Lester Ingber]

Replying to ingber:

P.S.:

I'm running VB & VBoxAdditions 4.04.

Lester

[cary co]

It's funny that some work and some do not work on my system, linux guest in linux host:

In the guest:

$ ls -l total 88 lrwxrwxrwx 1 ww ww 3 2010-10-19 17:53 allp -> b77 drwxr-xr-x 1 ww ww 4096 2011-03-04 08:59 b132 drwxr-xr-x 1 ww ww 4096 2009-12-04 17:58 b77 drwxr-xr-x 1 ww ww 4096 2011-03-03 16:35 latest ....

In the host:

$ l total 92 drwxr-xr-x 23 ww ww 4096 2011-03-04 13:03 . drwxr-xr-x 3 ww ww 4096 2010-08-05 17:50 .. lrwxrwxrwx 1 ww ww 3 2010-10-19 17:53 allp -> b77 drwxr-xr-x 3 ww ww 4096 2011-03-04 08:59 b132 drwxr-xr-x 3 ww ww 4096 2009-12-04 17:58 b77 lrwxrwxrwx 1 ww ww 4 2011-03-04 13:03 latest -> b132 ....

[cary co]

Sorry, post again.

It's funny that some work and some do not work on my system, linux guest in linux host:

In the guest:

$ ls -l
total 88
lrwxrwxrwx 1 ww ww    3 2010-10-19 17:53 allp -> b77
drwxr-xr-x 1 ww ww 4096 2011-03-04 08:59 b132
drwxr-xr-x 1 ww ww 4096 2009-12-04 17:58 b77
drwxr-xr-x 1 ww ww 4096 2011-03-03 16:35 latest
....

In the host:

$ ls -l
total 84
lrwxrwxrwx  1 ww ww    3 2010-10-19 17:53 allp -> b77
drwxr-xr-x  3 ww ww 4096 2011-03-04 08:59 b132
drwxr-xr-x  3 ww ww 4096 2009-12-04 17:58 b77
lrwxrwxrwx  1 ww ww    4 2011-03-04 13:03 latest -> b132
....

[Brian Campbell]

Replying to caryco:

Sorry, post again.

It's funny that some work and some do not work on my system, linux guest in linux host:

I've got a guess as to why that might happen, but it might be a day or two before I can check. It would be interesting to know if it's always the same files, or if it changes.

Replying to ingber:

Is this because of the inode condition above, which seems to only apply to my local VB?

I doubt it - I don't think rsync pays any attention to inode numbers unless you tell it to do something with hard links. It seems more likely that you're hitting the same bug as caryco.

[cary co]

Replying to bacam:

Replying to caryco:

Sorry, post again.

It's funny that some work and some do not work on my system, linux guest in linux host:

I've got a guess as to why that might happen, but it might be a day or two before I can check. It would be interesting to know if it's always the same files, or if it changes.

It doesn't change, at least, I haven't seen it changed yet.

If I further ls into b132, I can see the real content inside it. But if I 'ls -al latest', it shows the content of the root of the shared folder, and all symlinks there shown as real directories again.

[Brian Campbell]

Replying to caryco:

Replying to bacam:

Replying to caryco:

I've got a guess as to why that might happen, but it might be a day or two before I can check. It would be interesting to know if it's always the same files, or if it changes.

It doesn't change, at least, I haven't seen it changed yet.

If I further ls into b132, I can see the real content inside it. But if I 'ls -al latest', it shows the content of the root of the shared folder, and all symlinks there shown as real directories again.

So I didn't manage to get the same behaviour, but I did find a couple of bugs that might explain it. The fix for those should be in the next version, but if you want to try building the guest's kernel modules from source the patch is at ​http://vbox.innotek.de/pipermail/vbox-dev/2011-March/003775.html.

[Richa]

I have vbox 4.1.2 installed along with the guest additions and the ext pack. I am still not able to create symlinks in shared folders.

I am working as root. have added root to the vboxsf group. have all write permissions on the shared folders

ln -s fails with symlink failing with EPROTO.

guest is red hat linux uname -a Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:54 EDT 2009 i686 i686 i386 GNU/Linux

host is windows 7 (64 bit )

I am really stuck because of the failure to create the symbolic links

[Frank Mehnert]

This should work on Windows hosts as well. However, there are special permissions required to be able to create a symbolic link on Windows.

[Richa]

what permissions are required ?

[Frank Mehnert]

See ​here, search for Create Symbolic Link privilege.

[Richa]

if I need to make symbolic links from my Linux guest, what permissions shall I need to give I tried everyone on my computer however that did not work

Is there a specific user that I need to give permissions to

[Frank Mehnert]

Sure, the user who is starting the VM...

[Richa]

I gave it to everyone .. but did not work .. :-(

[Richa]

Still results with Protocol Error ln: creating symbolic link 'dest' to 'source': Protocol error

[Richa]

run the virtual box as administrator to get it going . :-) Thanks

[studgeek]

Links seem to be having problems again starting with 4.1.8. It's being discussed in this thread - ​https://forums.virtualbox.org/viewtopic.php?f=3&t=47014.

I and many others are seeing the following: $ ln -s a b ln: failed to create symbolic link `b': Read-only file system $ ln a b ln: failed to create hard link b' => a': Operation not permitted

My personal setup is the following, but it happening with MacOSX and Ubuntu hosts as well.

Host: Windows XP
Guest: Ubuntu Server 12.04
VirtualBox: 4.1.14

[David Biesack]

I still see this in VirtualBox 4.2.10
Host: XUbuntu 13.04
Guest: CentOS 6.3
Share Folder is an ext4 local drive
host: /dev/sda4 on /local type ext4 (rw,errors=remount-ro)
guest: local on /media/sf_local type vboxsf (uid=394,gid=100,rw)

hard links are pretty important; tar files often contain hard links, making them unusable in a shared folder. Also, if one tries to /bin/mv a folder from a local filesystem such as /tmo (and it contains hard links) to a shared folder, the hard links won't be copied correctly and the /bin/mv command will 'fail', which can break makefiles or other tools.

[kburtch]

Hard-links are still an issue in 4.3.6.

Host: Sun/Oracle X3-2 running Solaris 11.1
Client: RedHat Enterprise Linux Server 6.4

I managed to work around the symlink issue as described in https://www.virtualbox.org/ticket/10085#comment:12 - thanks for that.

Unfortunately, hard-links are still unusable.

$ ln errlog example
ln: creating hard link `example' => `errlog': Operation not permitted

I wanted to use sharedfolders for their performance (NFS from host to vm is painfully slow), and found out the hard way that hard links fail with "Operation not permitted". We're extracting numerous large tarballs which contain many hardlinks (each) as a regular process.
This bug makes using sharedfolders impossible for this purpose.

[khader]

does not work on 4.3.6r91406 too

Host: Win 7(64bit) with cygwin Guast: Linux Mint 15 Olivia (64bit) Shared folder is a local ntfs drive

[hartmut]

Why was this closed as "obsolete" without further comment?

It still isn't solved in 5.1.18 (on Ubuntu 16.10), and it e.g. prevents mounting the postgresql datadir /var/lib/postgresql to a synced folder:

$ apt install postgresql-9.5
[...]
Creating new cluster 9.5/main ... 
  config /etc/postgresql/9.5/main
  data   /var/lib/postgresql/9.5/main
  locale en_US.UTF-8
LOG:  could not link file "pg_xlog/xlogtemp.3730" to "pg_xlog/000000010000000000000001": Operation not permitted
FATAL:  could not open file "pg_xlog/000000010000000000000001": No such file or directory
child process exited with exit code 1 
initdb: removing contents of data directory "/var/lib/postgresql/9.5/main"
Error: initdb failed
Error: could not create default cluster. Please create it manually with

  pg_createcluster 9.5 main --start

or a similar command (see 'man pg_createcluster').

/var/lib/postgresql is a synced folder using vboxsf

$ mount  | grep post
var_lib_postgresql on /var/lib/postgresql type vboxsf (rw,nodev,relatime)

[hartmut]

Maybe this bug should stay closed as the soft link aspect of this is indeed fixed, continuing with #4290 which was explicitly about hard links, and so far marked as duplicate ...

[GnomeUser]

Replying to hartmut:

Maybe this bug should stay closed as the soft link aspect of this is indeed fixed

Doesn't work in VBox 6.1.6 ln: failed to create symbolic link './tmp': Operation not permitted

[Frank Batschulat (Oracle)]

OK, this bug should have stayed closed.

1) the original complaint of this bug, the failure to interpret and properly display symbolic links from the host side within the guests shared folder file system is fixed.

2) the unsupported hardlink in the guest issue has its own bug #4290

3) the unsupported symlink in the guest issue has its own bug #10085