Use Windows share with "remote-to-remote" links in Linux

Question

I mount a Windows share on recent Linux with default options that work.

But on the Windows share a new symbolic link with the name "archive" has been created that point to another Windows share (on server2). This kinks of links seems to be called "remote-to-remote" symbolic links. Normal "local" links work on the mounted share on the Linux side. Windows clients support that after enabling these kind of links via https://helpcenter.netwrix.com/NA/996/Configure_IT_Infrastructure/File_Servers/Enable_Symlink.html

On Linux this link "archive" looks like this: archive -> '/??/UNC/server2/folder'

So it seems that the Linux does not understand this kind of link. It could use the same credentials since I can mount "//server2/folder" manually but I need it in the "archive" folder/link.

I already tried the "mfsymlinks" option in the /etc/fstab line with no success.

If I try to mount the //server2/folder over "archive" I get the error: archive: No such file or directory

Answer 1

Linux can't easily handle such links client-side because it does not have a fixed path for SMB shares. Your symlinks work on Windows clients because \\<server>\<share> is automatically understood on any Windows client without any custom configuration, but that does not apply to Linux where each share is manually mounted on an arbitrary, user-chosen path.

Now Linux does understand the symlinks, in that it shows you exactly where their target goes (Windows symlinks use NT paths under the hood so \??\UNC\<server> is actually correct), it's simply that there's no automation on Linux to mount SMB shares at the target paths. Even if the target had been translated to //<server> it wouldn't have helped here.

That being said, /??/UNC is a perfectly valid (if weird) Linux path, so you can use the lack of \\ translation to your advantage: you can literally mkdir -p "/??/UNC/server2/folder" and configure your /etc/fstab to mount the other share there. (The question marks aren't a problem.)

In fact you could even configure the autofs service to have a special autofs map at /??/UNC which automatically mounts SMB shares, similar to how autofs would typically be used with NFS.)

But I would instead suggest a different approach: rather than symlinks, use the DFS feature found in SMB. (Not DFS-R, just regular DFS.) Unlike symlinks, DFS referrals are followed by the SMB client rather than being exposed to the filesystem – there is no "symlink path" to be shown to the user. This means the client can mount the target share directly on top of the DFS junction, which allows both Windows and Linux clients to follow DFS referrals without any special configuration.

(You can create "server-hosted DFS namespaces" on any Windows Server machine, including converting an existing share to a DFS namespace. You can also use DFS with Samba, but with a bit more effort.)