ixnas breaks shadow_copy_zfs

[bmh.01]

I've checked the current issues jira and searched on here as well without finding anything but has anyone got these two to work together?

They both seem to work OK in isolation but if I enable them together then ixnas appears to jump in before shadow_copy_zfs can translate the snapshot request to a ZFS snapshot directory and I get the following error along with no previous versions returned.

Code:

smbd[75792]: [2019/06/27 11:10:35.313494,  0] ../source3/modules/vfs_shadow_copy_zfs.c:151(shadow_copy_zfs_strip_gmt)
smbd[75792]:   shadow_copy_zfs_strip_gmt: returning root of share
smbd[75792]: [2019/06/27 11:10:35.314315,  0] ../source3/modules/vfs_ixnas.c:366(zfs_get_nt_acl_common)
smbd[75792]:   zfs_get_nt_acl_common: ixnas: acl_get_file() failed for @GMT-2019.06.27-10.03.01/userdir: No such file or directory

I'm going to try a few other things but wanted to check if i've missed something obvious before submitting a bug report.

 

[anodos]

I've checked the current issues jira and searched on here as well without finding anything but has anyone got these two to work together?

They both seem to work OK in isolation but if I enable them together then ixnas appears to jump in before shadow_copy_zfs can translate the snapshot request to a ZFS snapshot directory and I get the following error along with no previous versions returned.

Code:

smbd[75792]: [2019/06/27 11:10:35.313494,  0] ../source3/modules/vfs_shadow_copy_zfs.c:151(shadow_copy_zfs_strip_gmt)
smbd[75792]:   shadow_copy_zfs_strip_gmt: returning root of share
smbd[75792]: [2019/06/27 11:10:35.314315,  0] ../source3/modules/vfs_ixnas.c:366(zfs_get_nt_acl_common)
smbd[75792]:   zfs_get_nt_acl_common: ixnas: acl_get_file() failed for @GMT-2019.06.27-10.03.01/userdir: No such file or directory

I'm going to try a few other things but wanted to check if i've missed something obvious before submitting a bug report.

Looks like an issue with ordering the VFS modules. I'll attach a patched generate_smb4_conf.py script later today when I have a chance.

 

[anodos]

This is assuming you're using FreeNAS 11.2 and not nightlies.

 

[bmh.01]

Yes i'm running 11.2-U5, the updated docs drew my attention to the ixnas module.

 

[bmh.01]

Looks like an issue with ordering the VFS modules. I'll attach a patched generate_smb4_conf.py script later today when I have a chance.

You've pointed me in the right direction and I've modified it to make ixnas a special vfs object so it's appended last and it does indeed seem to be working now. I'm not sure if anything else needs to be modified apart from maybe default options.

One more question, before the upgrade to U5 i'm sure that home directory previous versions (Use as home share ticked) worked but they will throw a permission denied error now as the .zfs/snapshot directory is outside of the exported share? If I enable wide links then it works again but obviously security wise this isn't a great idea. With dataset-per-user you get away with it.

 

[bmh.01]

Actually, I think it's still an issue with the previous versions as it's returning the home dataset root rather than the users folder which is why it throws an permission denied error.

 

[anodos]

Actually, I think it's still an issue with the previous versions as it's returning the home dataset root rather than the users folder which is why it throws an permission denied error.

If I recall correctly, I still have to give the connectpath() function a little love in that module. It's not happy if the .zfs/snapshot directory is outside of the share path. You can work around it by setting "widelinks = yes" and turning off unix extensions for the share.

 

[anodos]

Which if I read your post is exactly what you wrote. Wide links in themselves aren't a much of a security risk unless you've enabled "unix extensions" and "allow insecure widelinks".

 

[bmh.01]

Ok I'm not using unix extensions so I'll give it a try for a bit.

There is another issue which I assume is related to the work needed in the connectpath() function you mention in that the previous versions only work from the root of the users folder. On the previous versions tab of any folders there are no snapshots listed, I haven't tried it with a file. Also when I do open a snapshot from the root of the users folder it goes to the root of the Homes dataset rather than the users folder.

I assume there's no way around this at this point?

 

[anodos]

Ok I'm not using unix extensions so I'll give it a try for a bit.

There is another issue which I assume is related to the work needed in the connectpath() function you mention in that the previous versions only work from the root of the users folder. On the previous versions tab of any folders there are no snapshots listed, I haven't tried it with a file. Also when I do open a snapshot from the root of the users folder it goes to the root of the Homes dataset rather than the users folder.

I assume there's no way around this at this point?

Pretty much. I plan to fix this stuff soon, but have a few other irons in the fire that need attention.

 

[anodos]

Ok I'm not using unix extensions so I'll give it a try for a bit.

There is another issue which I assume is related to the work needed in the connectpath() function you mention in that the previous versions only work from the root of the users folder. On the previous versions tab of any folders there are no snapshots listed, I haven't tried it with a file. Also when I do open a snapshot from the root of the users folder it goes to the root of the Homes dataset rather than the users folder.

I assume there's no way around this at this point?

I just pushed a fix for 11.3 for both of these issues (non-widelink opens and the incorrect chdir). I will also try to backport the fix to 11.2.