Trying to create a symlink with ln -s [target path] [symlink name] on Ubuntu 10.04 and 11.04 guests:
My question: Is it possible to create symbolik links on hgfs shares at all???
I saw http://communities.vmware.com/thread/297284 as well as http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1007277&sl..., but they don't really match.
So - is there a way to create symlinks on a Linux guest's shared folder and - if so - which one?
We also have a need for Windows Host support for symbolic links in shared folders. At our company, we use Vagrant to allow developers to create simulated versions of our production Linux environment in order to develop applications in a consistent and predictable environment. By using Vagrant and VirtualBox, our developers are able to use their Mac or Windows systems to develop Linux applications, which as discussed above will likely have requirements to create symbolic links. Two such instances we encounter - using Node.js Package Manager (npm), which creates symbolic links when installing packages and using Python virtual environments (virtualenv), which creates symbolic links to system packages. However, now that Vagrant has VMWare support, I wanted to use that (as I've been a VMWare customer since its initial offering). Unfortunately, it appears that Virtualbox offers a feature that VMWare does not. This issue means I will have to use Virtualbox and I cannot recommend VMWare to my colleagues for their development. I will also be obliged to inform Vagrant that their VMWare plug-in is not a "drop-in replacement" for Virtualbox as advertised.
In my mind, this simple fact should be a black eye for VMWare and something that VMWare should make a priority to support.
I recognize the challenge here - that NTFS did not have suitable symbolic link support in the file system (or API) for some time. Despite that, it's conceivable that one could desire to use a FAT file system as a shared folder. I believe VMWare would do well to simulate symbolic links in this case. In any case, I would expect at least matching the free competitor's offering.
Thanks for reporting your use case.
I will update the feature request with your details.
Please note however, there is still no guarantee that the Workstation product manager will give this sufficient priority but it all helps.
It would be a fun feature to add and work on.
I've read all the posts regarding symlinks on linux guests in Workstation and I was wondering if things got any better in Workstation 12? Lack of this feature is a real pain for me...
Hello Adam, and all,
I am sorry to say that support for symlinks on Windows hosts has not made progress but it is still on my radar.
I have been getting a Linux FUSE client up and going and some security issues and have not been given adequate time to focus on some the new feature support.
I am going to update the feature request and try and get time to work on this even incrementally so that I make progress to enabling this in the future.
Apologies for the bad news.
Same here. We build Symfony projects where asset management is being done by symlinking them. Ofc it is possible to fallback to copy strategy, but that is super annoying as in large projects build times increase drastically, you end up watching how stuff is being copied instead of writing code. So basically we are forced to a) use VirtuaBox (slow and what was a point to buy VMware then?); b) change host OS (I prefer not to) c) do not use mounting for syncing files in host and VM (makes workplace configs for Windows hosts special).
And I have feeling that your PO misinterprets OS useage numbers. You know, for Windows users virtualization is unavoidable necessity. That can't be told about Linux or OSX users. We still use VMs on Linux and OSX, but because we choose to, not because we do not have alternative. Lots of us use OSX or Linux for development, not because we want to, but we simply do not have real option to use Windows hosts as virtualization on them have quite some issues. What I am trying to say, OS usage numbers are consequence of lacking full Windows support. If you read them as reason to ignore and give low priority, you basically miss quite some market.
Having faced this challenge too, I eventually figured a way around it: using SAMBA.
I simply installed SAMBA on the Linux guest and set up a folder (with a 777 permission setting) which was then accessible from the Windows host with full read/write capability. Note that I set up the ubuntu (guest ) VM to use bridged networking, so the folder can then be mounted as a network share in Windows.
I will add your comments to my tracking bug for this issue and symlink feature support.
Unfortunately, for all of us, including myself, there has been very little support for spending any time on this feature.
I will keep pushing and hope that it can be given resources to make progress, but so far we are all out of luck.
Just thought I'd note that in Windows 10 with the Windows Subsystem for Linux, Microsoft now has some sort of format for linux symlinks on NTFS (separate to the NTFS native links). Using bash for windows I can create a symlink on an NTFS drive. These links don't function under windows but do work within the bash subsystem (looks like it's using some sort of NTFS metadata as has size 8 bytes and size on disk 0 bytes).
Perhaps VMWare could produce these types of files. It isn't going to meet the use-case of being able to use linux symlinks within windows apps but would allow symlinks in shared folders and interop between multiple linux guests as well as between a linux guest and bash on windows. Plus it is sort of adhering to a Microsoft standard, they could add support for these symlinks on the windows side. It's also likely easier to implement as I imagine the Bash symlinks fairly closely mirror the linux format so hopefully don't require complex translation.
Is there any progress on this issue ? (creating symlinks on linux guest) OR any plans for future versions of VMWare Work Station ?
This is really blocking our efforts, and we may have to start looking into other VM solutions.
I just want to add my voice to this discussion. My company is about to switch to VirtualBox specifically because of the symlink issue. It seems that Workstation 15 still does not support symlink creation over in the hgfs shared folders for Linux, and this use case has become critical to our software development build system. I can't believe this issue has been ignored for years. You are going to lose this customer over this specific issue.
Along those lines.. I just literally walked away from buying Workstation as a product because initial testing as a product revealed that the lack of this feature would render it useless for our purposes. Add that to the direct loss of revenue because of this feature. It's probably low hanging fruit too.
Doing a bit of research. As a result of WSL, NTFS now supports hard links, soft links and even a couple of other things that Linux does not. There really isn't any reason that a windows host OS should not be able to create soft and/or hard link on behalf of a guest OS or for the guest OS to interpret these links and follow them.
So really not ideal... Very annoying that neither side supports this properly. We need this functionality because a ton pictures are associated with user accounts, and storing in side them vm is impractical at best. We don't do it in production, so why are we forced to do it here?
Anyways, we simply mount the remote file system in windows, then use the mklink tool (mklink /D CLUSTER D:\gluster-cluster) and things appear to be working.
Sorry to hear that this has been a source of frustration. I have not been able to work on this feature in a long time.
The feature itself has been moved to a different group who I am trying to get to deal with these type of issues and requests.
Sorry for the very slow going here.
I am going to refile this to get their attention and that it is an important piece of functionality.
So far, they have been focusing more on performance issues due to product manager's input.
We will see if they can spend time on this too though.
Thanks for your understanding.