5

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

Sibo Lin
  • 339
  • 1
  • 5
  • 16

1 Answers1

4

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

metamatt
  • 13,809
  • 7
  • 46
  • 56
  • I understand and agree with your reasoning for why my symlinks currently fail. So one possible solution might be to restructure my folder structure, such that Data_2011 is a folder that contains both symlinks and a Data subfolder. This is really not ideal, however. Is there any way to get these links to work without merging the directories? I've tried using a relative link such as "ln -s ../Data/datafolder symlink", but I don't get a different result. – Sibo Lin Jan 24 '11 at 08:57
  • Update: nevermind--making a symlink with a relative location DOES work, so I'll mark this question Answered. I actually chain my ln command within a find command ("find -exec ln -s}, so it'll take a bit more finangling to get it all working in my situation. Thanks for the help! – Sibo Lin Jan 24 '11 at 22:48
  • Thanks a lot. You answer helps me with Sonos media library setup on macOS High Sierra – ursa Jan 02 '18 at 02:37