CORE to SCALE migration - smb no access any account

[rexit1982]

So I went ahead and did a migration from Core Scale Nightly. Data is good, config all looks right, NFS is working as expected. But the devil that is smb won't let me into any of my shares, seemingly regardless of what creds I use. everything I try and some of my older scripted processes from other machines end up wiht an entry in auth_audit.log that says NT_STATUS_NO_SUCH_USER. I'm using all local users and made sure the samba box is checked. It even tells root to bugger off trying to do net rpc user or net rap user from the command line.

getent passwd, getent group, id <username>, groups<username> all yield expected results, although I don;t remember if that is winbind calls or native to the linux os.

Last thing I thought of was unchecking the microsoft and samba boxes on the user, save it, recheck save again. This did not seem to change any behaviors.

Any thoughts?

 

[rexit1982]

oo, now I'm learning to Jira... this might be my issue.

https://jira.ixsystems.com/browse/NAS-111655

 

[anodos]

I'm currently working pretty heavily in this area getting ready for next beta with clustered SMB. Things are in flux. Try updating to another nightly over the weekend and see if the situation improves. If not, file a jira ticket.

 

[rexit1982]

Gotcha, Improved where I get a share list with the nightly from today but a new issue seems to be preventing access.

https://jira.ixsystems.com/browse/NAS-111719

[2021/08/06 17:44:32.624236, 0] ../../lib/util/modules.c:49(load_module)
Error loading module '/usr/lib/x86_64-linux-gnu/samba/vfs/zfsacl.so': /usr/lib/x86_64-linux-gnu/samba/vfs/zfsacl.so: cannot open shared object file: No such file or directory
[2021/08/06 17:44:32.624431, 0] ../../source3/smbd/vfs.c:185(vfs_init_custom)
error probing vfs module 'zfsacl': NT_STATUS_UNSUCCESSFUL
[2021/08/06 17:44:32.624674, 0] ../../source3/smbd/vfs.c:397(smbd_vfs_init)
smbd_vfs_init: vfs_init_custom failed for zfsacl
[2021/08/06 17:44:32.624851, 0] ../../source3/smbd/service.c:637(make_connection_snum)
make_connection_snum: vfs_init failed for service tv
root@gerald[/var/log/samba4]# ll /usr/lib/x86_64-linux-gnu/samba/vfs/ | grep zfs
-rw-r--r-- 1 root 39792 Aug 5 13:39 shadow_copy_zfs.so
-rw-r--r-- 1 root 31600 Aug 5 13:39 zfs_core.so
-rw-r--r-- 1 root 15216 Aug 5 13:39 zfs_fsrvp.so
root@gerald[/var/log/samba4]#

 

[anodos]

Okay. You have auxiliary parameters incompatible with Linux. Comment them out.

 

[rexit1982]

Okay. You have auxiliary parameters incompatible with Linux. Comment them out.

vfs objects = zfs_space zfsacl streams_xattr
So that vfs objects thing isn't supposed to be there? I figured the migration added that for compatibility, if core has to add that to work the migration tooling might need to remove it? All my shares have it, I promise I didn't put it there!

 

[anodos]

Migration to SCALE shouldn't put those there. What version did you migrate from?

 

[rexit1982]

Migration to SCALE shouldn't put those there. What version did you migrate from?

TrueNAS CORE 12.0u4 I believe, I think the system started as FreeNAS 11.something.

 

[rexit1982]

Migration to SCALE shouldn't put those there. What version did you migrate from?

Just took a test vm from 11.1 to 21.08SCALE, those aux parameters get put in by FreeNAS/CORE it appears and they stay put through the migration tool to scale. I put some screen grabs on that jira ticket.

 

[anodos]

Just took a test vm from 11.1 to 21.08SCALE, those aux parameters get put in by FreeNAS/CORE it appears and they stay put through the migration tool to scale. I put some screen grabs on that jira ticket.

Directly from 11.1 to 21.08 or through intervening steps (i.e update to 12.0-U5, then SCALE)?

 

[rexit1982]

Directly from 11.1 to 21.08 or through intervening steps (i.e update to 12.0-U5, then SCALE)?

In that pass I took it through every major revision so it was closer to what had happened to my system, I was mainly trying to prove to myself that I did not at some point put those random parameters on all my shares. Looks like there were some changes the VFS stuff specifically in 11.3 and then in 12.0 they were situationally moved to aux params based on the comments to the jira ticket.

 

[anodos]

Right, technically samba is doing the correct thing. I don't think that it's safe to perform a migration in the general case of vfs modules being in auxiliary parameters. Probably best we can do is disable the share in the GUI and generate an alert to let admin fix it (possibly commenting out the line).