#818 closed defect (fixed)
vboxvfs lacks support for host side symbolic / hard links
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 )
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.
Attachments (3)
Change History (104)
comment:1 by , 16 years ago
Guest type: | other → Linux |
---|
comment:2 by , 16 years ago
Component: | other → shared folders |
---|
comment:3 by , 16 years ago
comment:4 by , 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 , 15 years ago
I just ran into the same issue over here. Does Oracle plan to support this in the future?
comment:6 by , 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 , 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
comment:8 by , 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 , 15 years ago
Version: | VirtualBox 1.5.0 → VirtualBox 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 , 15 years ago
Summary: | vboxvfs lacks symbolic link support → vboxvfs lacks support for symbolic / hard links |
---|
comment:12 by , 15 years ago
Adding a comment here is enough to receive all further comments of this ticket.
comment:13 by , 15 years ago
Same goes for version 3.0.6. Please add support for symbolic links and increase priority.
comment:16 by , 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 , 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 , 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 , 15 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 , 15 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:23 by , 15 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 , 15 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.
comment:25 by , 15 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!
follow-ups: 28 30 comment:27 by , 15 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.
follow-up: 35 comment:28 by , 15 years ago
Replying to kblcuk: "Previous release" in my case would be 3.0.8
comment:29 by , 15 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.
comment:30 by , 15 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 , 15 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 , 15 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!
follow-up: 34 comment:33 by , 15 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.
comment:34 by , 15 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
comment:35 by , 15 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 , 15 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 , 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 , 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 , 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 , 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 , 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 , 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 , 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 , 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 , 14 years ago
Not having this is tough, really limits the usefulness of vboxvfs on linux. Count my vote too.
comment:47 by , 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 , 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 , 14 years ago
Attachment: | symlink2.patch added |
---|
Symlink reading patch for Linux; made against 3.2.6 OSE.
comment:49 by , 14 years ago
Vbox version 4.0.0 Host MacOS 10.6.5 Guest Debian Squeeze
This should be at least a Major priority.
follow-up: 51 comment:50 by , 14 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.
comment:51 by , 14 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 , 14 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.
follow-ups: 54 57 comment:53 by , 14 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?
comment:54 by , 14 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 , 14 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 , 14 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
comment:57 by , 14 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 , 14 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 , 14 years ago
Ah, yes. Sorry I left that out.
host: Ubuntu 10.10 (64-bit)
guest Ubuntu 10.04 (32-bit)
by , 14 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 , 14 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 , 14 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 , 14 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 , 14 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 , 14 years ago
Thanks for the patch again Brian! Applied a similar fix to SVN and verified that it works.
comment:66 by , 14 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 , 14 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?
follow-up: 69 comment:68 by , 14 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)
comment:69 by , 14 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.
follow-up: 71 comment:70 by , 14 years ago
bacam,
Any update on adding vboxsf support for link(2)? Thanks.
comment:71 by , 14 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 , 14 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:74 by , 14 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 , 14 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.
follow-up: 77 comment:76 by , 14 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
comment:78 by , 14 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 ....
follow-up: 80 comment:79 by , 14 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 ....
follow-up: 81 comment:80 by , 14 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.
follow-up: 82 comment:81 by , 14 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.
comment:82 by , 14 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 , 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 , 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:87 by , 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:90 by , 13 years ago
Still results with Protocol Error ln: creating symbolic link 'dest' to 'source': Protocol error
comment:92 by , 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
comment:93 by , 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 , 11 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 , 11 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 , 8 years ago
Description: | modified (diff) |
---|---|
Resolution: | → obsolete |
Status: | new → closed |
comment:97 by , 8 years ago
Resolution: | obsolete |
---|---|
Status: | closed → reopened |
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)
follow-up: 99 comment:98 by , 8 years ago
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 ...
comment:99 by , 4 years ago
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
comment:100 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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
comment:101 by , 4 years ago
Summary: | vboxvfs lacks support for symbolic / hard links → vboxvfs lacks support for host side symbolic / hard links |
---|
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.