Problem/Justification
When mounting ZFS datasets, with the snapshot directory visble, via NFS, the directories in .zfs/snapshot are empty. This appears to be due to the lack of a crossmnt option for the NFS export. If that option is manually added to /etc/exports, the snapshot directories in the NFS mounted dataset are populated. Having the ability to peruse ZFS snapshots over NFS exports is useful in allowing end users the ability to recover individual files and directories.
Impact
The benefit is that all TrueNAS users would have the option to enable this NFS export option to allow access to ZFS snapshots via NFS mounts. Assuming this feature is properly tested, I don’t see any disadvantages.
User Story
I imagine something as simple as a “crossmnt” checkbox in the NFS export menu would suffice.
Would this also include sub-datasets in a NFS exports? For example, I have datasets of pool/Video, pool/Video/TV, and pool/Video/Movies. Each of them needs a separate NFS export, and needs to be mounted separately. Would this option expose all of them to a single mount?
crossmnt
This option is similar to nohide but it makes it possible
for clients to access all filesystems mounted on a
filesystem marked with crossmnt. Thus when a child
filesystem "B" is mounted on a parent "A", setting
crossmnt on "A" has a similar effect to setting "nohide"
on B.
With nohide the child filesystem needs to be explicitly
exported. With crossmnt it need not. If a child of a
crossmnt file is not explicitly exported, then it will be
implicitly exported with the same export options as the
parent, except for fsid=. This makes it impossible to not
export a child of a crossmnt filesystem. If some but not
all subordinate filesystems of a parent are to be
exported, then they must be explicitly exported and the
parent should not have crossmnt set.
The nocrossmnt option can explicitly disable crossmnt if
it was previously set. This is rarely useful.
This option has serious security implications, for what are likely similar reasons you can’t enable insecure wide links in Samba on TrueNAS. Since datasets are indeed separate file systems, allowing a user to mount into one and traverse into another would be dangerous and bad practice. Especially in a world where people just mapall to root. :\
If you wanted to expose some dataset as ro, others as rw, or different dataset to different IP ranges, then clearly you would use separate exports.
But if @dan can use one export with the crossmnt option instead of several, the result is the same filesystem datasets are exposed to the client. Why is this less secure?
If you’re saying the UI should restrict users from making bad choices that’s a different matter. But AFAIK using the crossmnt option where appropriate is not bad practice. What I’ve always understood is good practice in Linux is to define a NFS root in a discrete directory tree which will keep users limited to that mount point and combine this with bind mounts.
Using bind mount means additional entries in /etc/fstab or using systemd-mounts. This “good practice” doesn’t fit with SCALE.
What is definitely not “good practice” is the continued use of terms alien to Linux in the NFS UI, you will not find the mapall option in the Linux exports man pages. This has simply been copied from TN CORE/FreeBSD and never changed. Of course, the magic “crossmnt” option does not exist in FreeBSD, which may explain in part why it does not appear as an option in SCALE.
Can you please elaborate on which security implications this are? With crossmnt, you are just exporting a directory tree as you see it in the mounted file system of the server, instead of a single dataset. The differentiation / security boundary without crossmnt is by mount points, which is in my point of view just as arbitrary for a security boundary as a directory tree (with crossmnt) is.
In the end you need to know what you are doing. But for operating a server that holds security relevant data, that should hopefully be the case anyway.
I’m not even saying this necessarily shouldn’t be available. AFAIK crossmnt did not function this way in FreeBSD. For @dan’s usecase it may be appropriate, but it depends. With proper UID/GID mappings, I’d be less concerned, but crossmnt and the mapall root combination is what scares me.
I’ve been struggling with this issue as well. I have a parent dataset shared with both SMB and NFS. Through SMB I can access all the child datasets, but NFS just showed empty directories. A couple days of troubleshooting on and off and ChatGPT led me to the crossmnt option which then led me here.
I created an account just so I could vote for this feature.
Even with these “security implications”, they could just default to not having crossmnt enabled and, say, have a tooltip or other kind of a warning in the UI about those implications. Then it’d be the user’s decision whether they are or are not a concern for the user.
I’m not sure I like all this nannying and hiding useful features that much.
Agreed. For an enterprise environment, not having this option available has caused some additional, unnecessary work for the folks we have running TrueNAS.
I’ve actually been having issues with TrueNAS missing some other enterprise features like the ability to use the quota command/rpc.rquotad via NFS and not having the ability to configure default user quotas on datasets without creating a script that interfaces with the API. It’s starting to feel like TrueNAS isn’t enterprise worthy and is geared towards small-business. That sentiment is echoed from my experience with iXsystems support as well.
Kind of like how they could have handled Auxiliary Parameters?
This has been the trend since the introduction of SCALE.
Cannot store syslogs in an encrypted System Dataset anymore. Not even as an option.
No more Auxiliary Parameters. Not even for the “Community” users or hidden behind a warning dialog option.
Cannot enabled swap on the boot drive SSD as a safety buffer for times when you might inadvertently stress your RAM’s limits. (Not long ago, if the installer detected your boot device is an SSD that is at least 64GB, it would offer to create and activate 16GB swap partition. On Core, mine has never been touched, but the cost is almost zero. Most of my boot-pool is only several GBs at most, and remains quiet. It’s nice to know that in unforeseen circumstances, I have swap that can prevent a system crash.)
As a counter-point, I will note that the number of issues with every upgrade has gone down SIGNIFICANTLY from those wild cowboy days on CORE. It was pretty rough for many years there.
This was intentional, we made a decision to properly expose individual options (where necessary) and avoid all the rampant foot-shooting people were doing by going in and setting manual parameters or whatnot.
If there are knobs / features that folks want to bring back, of course we will consider that. But not as a random list of “set your own set of flags which will break on upgrade” type behavior. We’re trying to be more deliberate in how we expose all the knobs, and will consider ones which have value for enough users to make sense for us to test and support them officially.
Edit: I will also note, some of the worst offenders were our own forums for this. Random tribal knowledge would get posted, and unsuspecting users would copy-n-paste things into a config not knowing what they did. And then blame the software when stuff went sideways 6, 9, 12 months or later.
TrueNAS “Community” Edition: Where none of the above is exposed in the GUI, and if you really want to expose such options, you have to click through a dire warning and disclaimer to unlock them. Then you are on your own and must deal with the consequences of your own foot-shooting.
TrueNAS “Enterprise”: Not in the GUI and no way to unlock or unhide them.
Bonus: If you do click through the warning and unlock Auxiliary Paramaters, then your system is flagged as “tainted”.
Not going to happen. Folks ignore all the warnings in the world and will still blame the software, giving it a bad reputation, even if the issue is 100% self induced. (We allowed it after all).
At the end of the day TrueNAS is an appliance, not a generic *nix distro for editing conf files by hand. If folks want that, there are plenty of distros to run and things can be fully hand-configured and supported manually.
In the UI we are going to do things the proper way, which is enable options when we are ready to test and support them so it is a smooth user experience overall. Cowboy days are over, at some point software has to mature and grow up.
Considering since making this shift we’ve more than doubled our install-base size (and still accelerating) with a massive reduction in the number of regression tickets coming in for major updates every 6 months, this has been the right call.
Again, if there are specific knobs that folks want to expose, a feature request is the right way to go. We will review and bring in the ones we can commit to making work for the long-haul.
Is there some mechanism that allows enterprise customers to put more weight on feature requests? It feels like their requests should be given more consideration than “does it have enough votes on the forum?”.
Those of us using SMB take this for granted (easy browsing and retrieval of files from snapshots, even with a client’s file browser). I was surprised when I was testing out an NFS share of a dataset. (Forgot which version of SCALE, in a VirtualBox VM. Don’t attack me.)
Meaning that NFS with crossmnt (if enabled) allows something that someone can already do via SMB: crossing filesystem boundaries (so long as they have proper permissions).
