wide links?

[Phil Dumont]

Is "wide links" supported in FreeNAS's version of samba?

Simple example...

On the FreeNAS machine, in a dataset called vol1:

Code:

[root@storinator2] /mnt/vol1# mkdir wide_links_test
[root@storinator2] /mnt/vol1# cd wide_links_test
[root@storinator2] /mnt/vol1/wide_links_test# cp /etc/passwd passwd_copy
[root@storinator2] /mnt/vol1/wide_links_test# ln -s /etc/passwd passwd_ln
[root@storinator2] /mnt/vol1/wide_links_test# ln -s /mnt/vol1/wide_links_test/passwd_copy passwd_copy_ln

Then I share /mnt/vol1/wide_links_test, as a CIFS share named "wide_links_test", with the following auxiliary parameters...

Code:

follow symlinks = yes
wide links = yes

...and un-check "Unix Extensions" in "CIFS Settings".

Then from a Windows client, in a cygwin shell:

Code:

$ cd //storinator2/wide_links_test
$ ls -l
total 3072
-rw-r--r-- 1 ???????? ???????? 1670 Jul  8 11:20 passwd_copy
-rw-r--r-- 1 ???????? ???????? 1670 Jul  8 11:20 passwd_copy_ln
-rw-r----- 1 phil     None     1670 Jul  7 10:46 passwd_ln
$ for i in *; do echo ==== $i ====; head -1 $i; done
==== passwd_copy ====
root:*:0:0:root:/root:/usr/local/bin/bash
==== passwd_copy_ln ====
root:*:0:0:root:/root:/usr/local/bin/bash
==== passwd_ln ====
head: cannot open `passwd_ln' for reading: Function not implemented

The accessibility of passwd_copy_ln shows that symlinks are being followed, but the inaccessibility of passwd_ln indicates that wide links is not being honored. Am I doing something wrong, or is wide links just not done in FreeNAS?

Note 1: No, I don't really want to share the passwd file. This is just a simple, contrived example.

Note 2: Yes, I know about the security implication of wide links. I want to do it anyway. When/if I get it working, I'm going to be sharing the symlink-containing directory read-only (CIFS and NFS), so no one will be able to put "bad" links on it.

samba config file attached

 

[dlavigne]

This post might help: https://forums.freenas.org/index.php?threads/symlinks-not-visible-via-samba-cifs.40195/.

 

[Phil Dumont]

This post might help: https://forums.freenas.org/index.php?threads/symlinks-not-visible-via-samba-cifs.40195/.

Thanks, but no, that didn't really help.

It turned out in that case that the poster's original assumption that it was a wide links issue was incorrect. Since the link and the intended target were in the same share, it wouldn't have anything to do with wide links. The problem there was that the link was created incorrectly. That link could not have been followed at the server, so of course the CIFS client couldn't have followed it. (The posted resolution was to use absolute path, but I don't think that's necessary. A relative path would probably work if it were the right relative path.)

I believe in my case, the symlink does work on the server (though I did not demonstrate it in my original post), and so should work on the client, if "wide links" were honored. So I remain of the opinion that, unlike the other post, my issue really is to do with wide links.

 

[dlavigne]

Let us know if you find the answer. I suspect it may have something to do with ZFS datasets.

 

[Phil Dumont]

Let us know if you find the answer. I suspect it may have something to do with ZFS datasets.

It looks as though you are exactly right. It appears to have everything to do with ZFS/non-ZFS and nothing to do with symlinks.

A little more experimenting has revealed the following:

• If the root of the samba share is a directory in a ZFS dataset:
  • samba will follow a link in that share that points to a different ZFS dataset, even in a different zpool (assuming correct settings for 'wide links' et al).
  • samba will not serve anything that results in a non-ZFS file system object. It apparently doesn't matter how you get to it. In the example in my original post, it was a symlink pointing to the non-ZFS object. But it appears to be so even when symlinks are not involved. I've tried creating subdirectories mntpnt1 and mntpnt2 in wide_links_test, and mounting file systems on them (a tmpfs on one and an nfs on the other), and I cannot, from the Windows CIFS client, traverse either of those directories, despite mode bits 0755. Double-clicking on the directory from Windows explorer gives an error dialog with "The request is not supported", and cd-ing to it in a cygwin shell gives "Function not implemented."
• If the root of the samba share is a directory in some other file system type (I experimented mostly with NFS), such restrictions don't appear to exist. Symlinks in that share to other file systems (ZFS or otherwise) are followed. Mount points are traversable.

Since what prompted me to ask the question originally is a desire to follow symlinks in a ZFS dataset whose targets are in NFS mounts, this affects me. (If you really want to know why I want to do this, see this post. But be warned. It's not pretty.)

However, the above suggests a workaround...

I'm already sharing the symlink-to-NFS-containing dataset via NFS.

So if I mount localhost:/path/to/symlink-to-NFS-dataset, and then share the nfs mount of the dataset over samba, the symlinks will be followed by samba.

Ugly? Sure. Kludgy? You bet. Security implications? Quite possibly. Oh well.

 

[anodos]

It looks as though you are exactly right. It appears to have everything to do with ZFS/non-ZFS and nothing to do with symlinks.

A little more experimenting has revealed the following:

• If the root of the samba share is a directory in a ZFS dataset:
  • samba will follow a link in that share that points to a different ZFS dataset, even in a different zpool (assuming correct settings for 'wide links' et al).
  • samba will not serve anything that results in a non-ZFS file system object. It apparently doesn't matter how you get to it. In the example in my original post, it was a symlink pointing to the non-ZFS object. But it appears to be so even when symlinks are not involved. I've tried creating subdirectories mntpnt1 and mntpnt2 in wide_links_test, and mounting file systems on them (a tmpfs on one and an nfs on the other), and I cannot, from the Windows CIFS client, traverse either of those directories, despite mode bits 0755. Double-clicking on the directory from Windows explorer gives an error dialog with "The request is not supported", and cd-ing to it in a cygwin shell gives "Function not implemented."
• If the root of the samba share is a directory in some other file system type (I experimented mostly with NFS), such restrictions don't appear to exist. Symlinks in that share to other file systems (ZFS or otherwise) are followed. Mount points are traversable.

Since what prompted me to ask the question originally is a desire to follow symlinks in a ZFS dataset whose targets are in NFS mounts, this affects me. (If you really want to know why I want to do this, see this post. But be warned. It's not pretty.)

However, the above suggests a workaround...

I'm already sharing the symlink-to-NFS-containing dataset via NFS.

So if I mount localhost:/path/to/symlink-to-NFS-dataset, and then share the nfs mount of the dataset over samba, the symlinks will be followed by samba.

Ugly? Sure. Kludgy? You bet. Security implications? Quite possibly. Oh well.

Re-exporting an NFS share located on another server via Samba isn't recommended. https://lists.samba.org/archive/samba/2012-August/168993.html

It'll work... kinda... sorta... mostly. But there is almost certainly a better way of doing things. Like the car below.

 

[Phil Dumont]

Re-exporting an NFS share located on another server via Samba isn't recommended. https://lists.samba.org/archive/samba/2012-August/168993.html

It'll work... kinda... sorta... mostly. But there is almost certainly a better way of doing things. Like the car below.
View attachment 12690

Well, yes, of course there's a better way of doing things. The one that springs immediately to mind, because it's been in mind all along, is to put enough drives in our new FreeNAS box to hold all our data, move the stuff off our old RAIDS to this bigger FreeNAS box, share it all from there natively without having to do NFS mounts on the FreeNAS box, and throw away the old RAIDS.

But that costs money. And I don't hold the company purse strings. And I and my fellow engineers have not historically been successful at convincing those who do hold the purse strings to loosen them very much just to replace something that already works well enough (kinda, sorta, like that, er car?) for something that is merely more elegant.

If you have anything more definite to offer than just "there's gotta be a better way" -- that costs significantly less than a boatload of disks -- I'd be happy if you'd share. Otherwise, I limp along with what I've got.