symbolic links work when shared to Windows or Linux (smb), but broken when shared to Mac (afp or smb)

Question

On a Mac, I have a shared folder, ~\Documents. There are two subfolders, Data and Data_2011, the former containing folders of files from the last several years, and the latter containing symbolic links to the folders in the Data folder that have been updated since Jan 1 2011. The links were created with the standard ln -s command.

When I mount the shared Documents folder on a Windows computer, the links work. When I mount on Linux using smb, the links work. When I use these links directly on the hosting Mac, they work. However, when I mount the Documents folder from a remote Mac, the soft links are broken. To be clear, I mount the Documents folder by going to Finder > Connect to Server > afp://xxx.xxx.xx.xx/ or smb://xxx.xxx.xx.xx/Documents

Any ideas for how to get these soft links to work when shared to a remote Mac?

-Sibo

Answer 1

Mac OS file sharing exposes symbolic links as actual symbolic links.

If I connect one Mac to another, using either AFP or SMB, I can confirm this.

Note that symbolic links are resolved by the client -- even in a non-file-sharing case this means relative paths in symbolic links can be tricky, and in this case involving network file sharing, it means the client computer needs to be able to see the target file (the target file must also be in a folder that's shared and mounted), and the path needs to be the same.

For example, if I create a text file named "foo" in my home directory, then do "ln -s foo symlink" to create a link to it named symlink, then mount that home directory from a second computer and do "ls -l" it's shown as "symlink@ -> foo", and if I cat the file I can read it. But if I create the symlink as "ln -s /Users/matt/foo symlink", then on the second computer ls -l shows it as "symlink@ -> /Users/matt/foo", and cat says "cat: symlink: No such file or directory". That's because on the second computer, /Users/matt is a local home directory that doesn't contain a file named foo (and if it did, anything resolving the symlink would see the local foo, not the foo shared from the first computer).

So basically: you can use "ls -l" to see where the symlink points, and note that the client computer will resolve the symlink and try to open whatever file has that name, which may or may not be what you expected.

(Probably the reason that your test worked from your Linux machine and not your Mac is that the Linux machine has more network shares mounted or with different names, such that the symlink target name was a valid filename on the Linux machine but not the Mac.)