VirtualBox

Opened 16 years ago

Closed 7 years ago

Last modified 4 years ago

#818 closed defect (fixed)

vboxvfs lacks support for symbolic / hard links — at Version 96

Reported by: Jan Owned by:
Component: shared folders Version: VirtualBox 3.0.4
Keywords: vboxsf vboxvfs shared folder symbolic link Cc:
Guest type: Linux Host type: other

Description (last modified by Michael Thayer)

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.

Change History (99)

comment:1 by Frank Mehnert, 16 years ago

Guest type: otherLinux

comment:2 by Frank Mehnert, 16 years ago

Component: othershared folders

in reply to:  description comment:3 by Bernhard M., 15 years ago

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.

comment:4 by Brett Williams, 15 years ago

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?

comment:5 by Yann, 15 years ago

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

comment:6 by Lucian, 15 years ago

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.

comment:7 by Yehoshua Shoshan, 15 years ago

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

in reply to:  description comment:8 by KuniGunther, 15 years ago

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.

comment:9 by Sander van Leeuwen, 15 years ago

Version: VirtualBox 1.5.0VirtualBox 3.0.4

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

comment:10 by Frank Mehnert, 15 years ago

Summary: vboxvfs lacks symbolic link supportvboxvfs lacks support for symbolic / hard links

comment:11 by wader, 15 years ago

How do i add as CC? just reply?

comment:12 by Frank Mehnert, 15 years ago

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

comment:13 by LoOoD, 15 years ago

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

comment:14 by Frank Mehnert, 15 years ago

Contributions are welcome.

comment:15 by John Whitley, 15 years ago

commenting to track this ticket.

comment:16 by smith.winston.101, 15 years ago

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

comment:17 by John Whitley, 15 years ago

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.

comment:18 by Frank Mehnert, 15 years ago

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.

comment:19 by antoinea, 14 years ago

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.

comment:20 by John Whitley, 14 years ago

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.

comment:21 by Technologov, 14 years ago

Added myself as CC on this issue.

-Technologov

comment:22 by cary co, 14 years ago

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

comment:23 by Giovanni Toraldo (gionn), 14 years ago

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.

comment:24 by smith.winston.101, 14 years ago

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.

in reply to:  description comment:25 by Johan, 14 years ago

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!

comment:26 by Johan, 14 years ago

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

comment:27 by kblcuk, 14 years ago

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.

in reply to:  27 ; comment:28 by kblcuk, 14 years ago

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

comment:29 by Frank Mehnert, 14 years ago

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.

in reply to:  27 comment:30 by paleo, 14 years ago

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

comment:31 by Iraê, 14 years ago

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

comment:32 by johno12345, 14 years ago

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!

comment:33 by ximo, 14 years ago

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.

in reply to:  33 comment:34 by paleo, 14 years ago

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

in reply to:  28 comment:35 by kblcuk, 14 years ago

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!

comment:36 by Craig Miller, 14 years ago

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.

comment:37 by levity, 14 years ago

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.

comment:38 by dma_k, 14 years ago

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

comment:39 by excsm, 14 years ago

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.

comment:40 by Klaus Espenlaub, 14 years ago

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.

comment:41 by Dwight Schauer, 14 years ago

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.

comment:42 by Dwight Schauer, 14 years ago

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

comment:43 by Robin Edgar, 14 years ago

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

comment:44 by kyleb, 14 years ago

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?

comment:45 by mankiko, 14 years ago

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

comment:46 by kami911, 14 years ago

Also affects me, please fix it. 3.2.6

comment:47 by gaarby, 14 years ago

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.

comment:48 by Brian Campbell, 14 years ago

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.

by Brian Campbell, 14 years ago

Attachment: symlink2.patch added

Symlink reading patch for Linux; made against 3.2.6 OSE.

by Brian Campbell, 14 years ago

Attachment: symlink3.patch added

As before, but with symlink creation too.

comment:49 by Junqian Gordon Xu, 13 years ago

Vbox version 4.0.0 Host MacOS 10.6.5 Guest Debian Squeeze

This should be at least a Major priority.

comment:50 by Frank Mehnert, 13 years ago

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.

in reply to:  50 comment:51 by Junqian Gordon Xu, 13 years ago

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.

comment:52 by Jon Kaczynski, 13 years ago

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.

comment:53 by Jon Kaczynski, 13 years ago

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?

in reply to:  53 comment:54 by Brian Campbell, 13 years ago

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.

comment:55 by Jon Kaczynski, 13 years ago

$ 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?

comment:56 by Jon Kaczynski, 13 years ago

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

in reply to:  53 comment:57 by Junqian Gordon Xu, 13 years ago

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.

comment:58 by Brian Campbell, 13 years ago

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.

comment:59 by Jon Kaczynski, 13 years ago

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

comment:60 by Junqian Gordon Xu, 13 years ago

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

by Brian Campbell, 13 years ago

Attachment: symlink-fix-4.0.0.patch added

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

comment:61 by adam, 13 years ago

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

comment:62 by adam, 13 years ago

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

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

comment:63 by Brian Campbell, 13 years ago

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.

comment:64 by Technologov, 13 years ago

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

-Technologov

comment:65 by Frank Mehnert, 13 years ago

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

comment:66 by Jon Kaczynski, 13 years ago

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

comment:67 by kiran_th, 13 years ago

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?

comment:68 by Peter van Dijk, 13 years ago

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)

in reply to:  68 comment:69 by Jos Backus, 13 years ago

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.

comment:70 by Jos Backus, 13 years ago

bacam,

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

in reply to:  70 comment:71 by Brian Campbell, 13 years ago

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.

comment:72 by Jos Backus, 13 years ago

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.

comment:73 by Jos Backus, 13 years ago

Over loopback, sorry.

comment:74 by krislie, 13 years ago

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.

comment:75 by Jos Backus, 13 years ago

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.

comment:76 by Lester Ingber, 13 years ago

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

in reply to:  76 comment:77 by Lester Ingber, 13 years ago

Replying to ingber:

P.S.:

I'm running VB & VBoxAdditions 4.04.

Lester

comment:78 by cary co, 13 years ago

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

comment:79 by cary co, 13 years ago

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

in reply to:  79 ; comment:80 by Brian Campbell, 13 years ago

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.

in reply to:  80 ; comment:81 by cary co, 13 years ago

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.

in reply to:  81 comment:82 by Brian Campbell, 13 years ago

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.

comment:83 by Richa, 13 years ago

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

comment:84 by Frank Mehnert, 13 years ago

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

comment:85 by Richa, 13 years ago

what permissions are required ?

comment:86 by Frank Mehnert, 13 years ago

See here, search for Create Symbolic Link privilege.

comment:87 by Richa, 13 years ago

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

comment:88 by Frank Mehnert, 13 years ago

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

comment:89 by Richa, 13 years ago

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

comment:90 by Richa, 13 years ago

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

comment:91 by Richa, 13 years ago

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

comment:92 by studgeek, 12 years ago

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
Last edited 12 years ago by studgeek (previous) (diff)

comment:93 by David Biesack, 11 years ago

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.

comment:94 by kburtch, 10 years ago

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.

comment:95 by khader, 10 years ago

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

comment:96 by Michael Thayer, 7 years ago

Description: modified (diff)
Resolution: obsolete
Status: newclosed
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use