How to fix «ln: failed to create symbolic link» / «Operation not supported» in a VMware Workstation Ubuntu guest?

VMware
,
1

2

It looks like this issue has not been solved for many years: communities.vmware.com/thread/312591

I ended up moving the directory out of my VM’s shared folder to a new location.
It seems to be installing fine now.
I don’t guess the symlink works when its in a shared folder.

stackoverflow.com/questions/40920896#comment69054665_40920896

Symbolic links seem to be a recurrent problem for VMWare shared directories between different operating systems.
Since QEMU (and PyREBox) require symbolic link creation for the build process, I recommend building it in a directory different from the hgfs shared folder.

github.com/Cisco-Talos/pyrebox/issues/12#issuecomment-320589824

Currently for Windows hosts symlinks are not supported.
We currently don’t have plans to add it either.

sourceforge.net/p/open-vm-tools/mailman/message/29280098

The VirtualBox shared folder filesystem doesn’t allow symlinks, unfortunately.
Your only option is to deploy outside of the shared folders.

github.com/hashicorp/vagrant/issues/713#issuecomment-3819309

3

sharedFolder0.followSymlinks = "TRUE" does not solve the problem.

kb.vmware.com/s/article/2045026

The underlying file system in Windows is NTFS which does not support symbolic links in the same way as Linux does.
The creation of symlinks in directories that are NTFS mounts (like the vagrant shared folders) will always fail.

github.com/hashicorp/vagrant/issues/5840#issuecomment-115051381

4

My workaround is to patch the Plugin::Instance.activate! method.

Locate the code:

Replace it with the code:

Discourse::Utils.execute_command('rm', '-rf', target)
begin
  Discourse::Utils.execute_command('ln', '-s', public_data, target)
rescue
  Discourse::Utils.execute_command('cp', '-r', public_data, target)
end

My topic in the official Discourse forum: Hgfs shared filesystem in VMWare does not support symlinks.