Nested/children zfs datasets are not seen through smb share on MacOS

Discussion in 'Solaris, Nexenta, OpenIndiana, and napp-it' started by RonanR, Apr 5, 2019.

  1. RonanR

    RonanR Member

    Joined:
    Jul 27, 2018
    Messages:
    30
    Likes Received:
    0
    Hi,
    I'm facing a strange problem:
    MacOS can't see and access nested dataset when accessing the main dataset using SMB.
    For example, I got two dataset, ds1 and ds2) mounted as:
    ds1 : /tank/ds1
    ds2 : /tank/ds1/ds2
    I set sharesmb to on on ds1, and for testing purposes, I set the ACL to everyone@ full_set to tank, ds1 and ds2
    When connecting to ds1 using smb on MacOS, I can't see ds2
    On Windows, no problem at all, I can access ds2 and read/write/delete in it
    I tested sharing ds1 through AFP using netatalk3, and this time on MacOS I can see and access ds2 without any problem.
    So it only concerns smb and MacOS
    I'm using OmniOS r151028 with napp-it 19-01c, and my MacOS version is 10.13.6
    Does anyone have any idea how I can get MacOS to see nested zfs datasets?
     
    #1
  2. gea

    gea Well-Known Member

    Joined:
    Dec 31, 2010
    Messages:
    2,241
    Likes Received:
    742
    You must understand the nature of ZFS

    When you locally list filesystems on a ZFS system and compare it to a local file listing on a Linux (ext4), Mac (HFS+) or Windows (ntfs) system, you may have the impression this is quite the same. But this is not true.

    Every ZFS filesystem is completely independent from others. While they have a mountpoint in the regular filesystem, they can have their own properties like snaps, clones, case sensitiveness, character set, quotas, reservations or permission settings like acl inheritance or aclmode.

    If you have nested ZFS filesystems and you traverse to a nested filesystem you can find yourself in a whole different filesystem environment. This is why Sun decided to make shares a strict ZFS filesystem property when they invented ZFS. On Oracle Solaris you cannot travese nested filesystems therefor via the kernelbased SMB server - for good reasons.

    On OmniOS, you can traverse nested filesystems via kernelbased SMB (at least from Windows) but with a lot of restrictions regarding Snaps as Windows previous versions and with a lot of possible problems when for example ACL or case settings are different in the filesystems.

    If you use other sharing services like netatalk or SAMBA, situation is different. The know nothing and care not about ZFS. They simply access the filesystem and share a folder and the folders below, does not matter if its a ZFS filesystem or a simple subfolder. This can work if all filesystems have the same settings. ZFS Snaps as Windows previous version may not work as expected as Snaps are related to a given filesystem. If critical settings are different you may end in a chaotic situation where you may not understand behaviours (something works in one folder and not in the other).

    So in the end, nested ZFS filesystems in a share are a bad idea or you must strictly know about the possible problems. With netatalk or Samba you should also use a share per filesystems and avoid nested ones below a share. Solaris with its kernelbased NFS and SMB sharing services forces you to do so, outside Solaris you should do as well.
     
    #2
    Last edited: Apr 5, 2019
  3. RonanR

    RonanR Member

    Joined:
    Jul 27, 2018
    Messages:
    30
    Likes Received:
    0
    Thank for your explanation. I wasn't aware at all of this restriction on Solaris. I indeed took great precaution when creating my nested zfs, all have the same properties as the main one (case insensitive, same record size, same nmband and atim settings).
    That's quite a huge setback for me as all my architecture is based on nested zfs fs. Indeed, it's a lot easier to apply a global quota and/or reservation to a group of zfs sub fs by setting it to the root one. I also use it for our data management system, like the archiving one, where I mount only the main zfs folder in order to access all sub fs.

    FYI, I have 4 "main" zfs fs shares each of them containing between 10 to 20 nested fs shares. I don't have a second level of nested shares.
    So far it's working fine with a Windows and a Linux server, but now I need to grant access to a MacOS system, so I'm kind of stuck...

    I can't use AFP as it brings characters encoding/decoding problems. I can't use SAMBA, at least at the moment, as I fear for instability and performances degradation, so this need serious testing beforehand.

    I'm open to reorganize my storage and way of working, but I don't see any possibility to achieve what I seek.
    Easiest way for me is for MacOS to see the nested fs, being fully aware of the possible problems which this can bring, but I don't know how to.
    If you have any suggestion, I'm all ears.
     
    #3
  4. gea

    gea Well-Known Member

    Joined:
    Dec 31, 2010
    Messages:
    2,241
    Likes Received:
    742
    The sub filesystem should be accessable when you enable smb sharing for it but behaviour can be different if you access the share directly or if you travers via the parent share.

    Usually with ZFS you should create a parent non-shared filesystem like data with the filesystems you want to share within - no sub filesystems below, only regular folders. ZFS settings to the parent data filesystem can be inherited.

    If you do not need different ZFS properties on multiple shares, use one shared filesystem with simple folders within.

    btw
    Do you use cifs://ip (SMB1) or smb://ip (SMB2) you connect the SMB share from a Mac.
     
    #4

Share This Page