Can I avoid that ln fails to create a symbolic link on a network share?

Rocky Linux Tech Help
1

I try to create a symbolic link like this

ln -s Compilations _Compilations

but I get the error “ln: failed to create symbolic link ‘_Compilations’: Operation not supported”.

It must have something to do with the directory I am in, because when I do the same in my home diretory it works. The directory where ln fails is on a network share. The fstab entry for that share looks like:

//[ip-address/music    /shares/music           cifs    credentials=/etc/cifs.creds,uid=[user],gid=[group],file_mode=0755,dir_mode=0755,_netdev 0 0

Is there a way to define this share so that I can do symbolic links?

2

The filesystem’s type is ‘cifs’. Does CIFS support symbolic links?
Does the actual filesystem that is shared via CIFS support symbolic links?

The answer to the first seems to be “maybe”, according to symlinks on Samba share created by linux client (mfsymlink) not working on server - Super User

1 Like
3

Thanks @jlehtone. I used CIFS only because it seemed easy to install. Is there another filessytem mounting layer which does support symbol links? Here my config:

  • The main OS is Rocky 8 (as VM on a Synology NAS).
  • The file system to mount is on the Synlogy NAS and I have enabled SMB and NFS for this volume.
4

NFS is the more common way to share files between Linux machines. It definitely supports symlinks.
By the link above, one should be able to use symlinks with CIFS, if mount options are appropriate.

5

For links within samba shares you have to have “insecure-wide-links” enabled. Here is what I have in smb.conf

# Allow Symlinks - Disable unix extensions 170110, re-enabled, should work
# in Samba 3.0.6 and later. Needed 'allow insecure wide links' to work
# default is yes
         unix extensions = yes
allow insecure wide links = yes
6

I am not sure you really understand what ‘allow insecure wide links’ does.
By default, Samba sets ‘follow symlinks = yes’, ‘wide links = no’, ‘allow insecure wide links = no’ and ‘unix extensions = yes’.
This means that Samba will follow symlinks inside the shares path, but not externally, but there is a proviso, in the latest Samba versions, ‘unix extensions’ has been renamed to ‘smb1 unix extensions’.
I hope from this, you can see that, because SMBv1 is turned off by default, symlinks no longer work.
What setting ‘allow insecure wide links = yes’ and ‘wide links = yes’ and turning SMBv1 back on does, security wise, it allows you to shoot yourself in the foot.

1 Like
7

You are right, making links doesn’t work anymore.
I do understand what wide links means, but since I’m the only user on the system that is not publicly available I have an acceptable risk.

The work around is to log into the server and make the links there with the correct user permissions as long as the linked directory is also an allowed share.

8

I did a little more experimenting and did find that I can make a link to a samba share as long as the link target is in my home directory. If you use ln -s then the command would be:

ln -s <source-file> ~/<target-name>

What you can’t do is host a link from one samba share to a target in another share. Which is what the default action is and does fail.

The minimum protocol my server uses is smb2.1
Since all my clients use 3.1 I can probably retire that line.

1 Like
9

@hortimech and @jbkt23 I am confused:

All these settings 'follow symlinks ', ‘wide links’, ‘allow insecure wide links’ and ‘unix extensions’, where can I set them? On the machine I mount the share on (Rocky Linux VM) or the machine which provides share volume (Synology NAS)?

10

You need to set them in the smb.conf file on the NAS, but there are a couple of ‘gotchas’, the first is that you will also have to set ‘server min protocol = NT1’ as well, you will also have to use SMBv1 everywhere else. The second is that the NAS is a synology device, they take an older version of Samba and add to and modify it and never share those modifications, so, while it should work, it might not work.

11

To address the OP’s original issue this is what I’ve found after disabling " linux extensions" and " allow insecure wide links" and rebooting the server.

You can not create links from the client side listing to in tree files or directories of the share. If there is a pre-existing link to a file or subdirectory in the shared hierarchy then you can follow those links out of the box with the default share settings. To create the desired link you have to create it by logging into the server and use ln -s <sourcefile> <pathInHierarchy>/<targetname> . The source and path to the target have to all be within the specific share.

1 Like
12

Are you sure?

According to man mount.cifs:

mfsymlinks
Enable support for Minshall+French symlinks(see UNIX Extensions - SambaWiki). This option is ignored when specified together with the sfu option. Minshall+French symlinks are used even if the server supports the CIFS Unix Extensions.

That option is used on the client, e.g.

mount -t cifs -o mfsymlinks ...

And it creates (text) files, even on Windows SMB servers, that the client uses like symlinks. The server is not any part of that. It does not need to. It is the CIFS driver that does the magick, just like filesystem (e.g. XFS) handles its “symlink” file objects.

(A similar feature can be found from rclone that can convert symlinks to text files that represent the links on upload, and can then (re)create symlinks on download.)

13

@jlehtone bingo. Adding “mfsymlinks” to the cifs mount command line made it possible to create symlinks on the client to the specific file on the share using the DE file browser which for me is Mates Caja. On Gnome I suppose this is Nautilus. No need to do as I described in my previous post.
I did have to review man mount.cifs to understand that mfsymlinks was an option and not an addon I needed to get.