Nesting Datasets with Different Presets?

TrueNAS General
, , ,
1

Hello,

So, I’d like to create a collection of nested datasets for storing backups. Something like:

/LiveBackups
/LiveBackups/SMB
/LiveBackups/SMB/TimeMachine
/LiveBackups/NFS

I don’t actually plan to store anything directly in LiveBackups, or to use it for a share. I just want use it as a parent for shared dataset settings.

Mostly, I want to do this for two reasons:

  1. A hierarchal organization is much cleaner and easier to manage in the TrueNAS Datasets GUI.
  2. I want to set default properties for all the datasets that will hold my backups, and only change them as necessary. Defaults I’m thinking of include:
    2.1. Recordsize
    2.2. User/Group for Ownership/Acesss
    2.3. Snapshot schedules

So, of course, I’m getting stuck at the beginning, with the Preset choice.

image
image1614×1394 93.6 KB

Obviously, the NFS child dataset needs the NFS type*, and the SMB datasets need the SMB type.

So, in that case, what’s the cleaner/more correct setting for the parent preset, especially considering I want to use it to set the default owner user/group and snapshot settings? Does it even matter? I know Generic will have me using Unix permissions, and SMB or Multiprotocol invokes the NFSv4 ACLs, but I’m not quite sure what to do with that information.

* Someday, I’m going to learn what the Multiprotocol preset is actually useful for. :stuck_out_tongue:

2

For this “unused” parent, I would set it to “Generic”. No need for any ACLs higher than where they are needed.

If you set it to “SMB” with defined ACLs, then it might cause strange permission issues for the “Generic” datasets that live underneath it.

A “Generic” parent won’t cause issues for a “SMB” child with ACLs.

EDIT: What is that loud sound I hear? Is @awalkerix flying over here with his fancy red cape, breaking the sound barrier? :scream:

I better leave this thread before he embarrasses me and shows everyone how wrong I am.

2 Likes
3

Thanks! This is exactly what I needed to know.

Though –

EDIT: What is that loud sound I hear? Is @awalkerix flying over here with his fancy red cape, breaking the sound barrier?

– that’s a bit concerning, not going to lie.

Is it normal to configure parent and child datasets like this? I’m new to ZFS, and a hierarchical organization like this makes sense given the way I’ve organized my non-ZFS filesystems for the last 32 years and my limited-but-growing knowledge of ZFS, but I’m curious if this seems overcomplicated or if I’m creating potential pitfalls I’m not aware of.

4

It’s up to you.

You need to plan for how you’re going to use snapshots, replications, and other dataset properties (like compression and recordsize), based on the “purpose” of the dataset and the types of files that live inside.

Can you have a dataset that contains movies, photos, and storage for source code and development, organized with folders? Sure. But you will lose out on granular control of snapshotting and replication specific data to backup pools.

This is why I am constantly looking up at the sky.

5

This is what I do for my SMB datasets. I have a root dataset called SMB configured as a generic dataset (no SMB Share) with lots of other datasets below that with differing permissions and individual SMB shares