TrueNAS 13.0-U1 is Now Available

[anodos]

FYI for AFP users, netatalk should be fixed in this release. There were some last-minute issues that I had to resolve with AFP metadata that was written in FreeBSD 11 and earlier. There is still basically a suicide switch in afpd to make it dump core if we hit a parsing error on AFP metadata. If this happens to you, please don't just think "it's still broken". Every core / debug I can get out of netatalk will move us toward having it in better shape for next U-release, and so file jira tickets if you run into problems and provide as much collateral and steps to reproduce as possible.

Hopefully, (fingers-crossed) all the major edge cases have been sussed out and we are good to go for the remainder of TrueNAS 13 lifecycle. It is important though to remember that the writing is on the wall for AFP and it is a good idea to use TrueNAS 13 as your opportunity to experiment / test migrating from AFP to SMB for your important workloads.

 

[j.lanham]

SID to name resolution failures are purview of winbindd. There are edge cases where we can show healthy (have stable connection to DC) even if idmapping is semi-broken (still have some cache, but new lookups fail). middlewared log and winbindd logs are particularly relevant here, but looking through them after a rollback may be somewhat complicated. In general if you encounter an issue post-upgrade it's best to generate a debug before rolling back, that way we have the maximum amount of collateral to fix issues.

One other piece of information that may have a bearing. All of the SMB shares are also NFS shares to be able to share data between our mainframe (which unfortunately is the easiest and most effective way of mounting files shares on the system) and still have accesibility to our users. It has to be that way because our network is a windows network and NFS on windows causes all kinds of problems. I also noticed that the warnings for that configuration went away when I upgraded. May that have some impact on the samba authorities? I'm still going to do a roll forward to try to generate some meaningful debug information and then roll back, but I was wanting to put that in to be complete.

 

[j.lanham]

SMB reports scare me as I use SMB, if it breaks how easy is to downgrade? I noticed there is a boot menu which seems to be a like a multi boot system?

If you are basing it on my reports, I have multiple complicating factors. If you upgrade and you have problems with access, you can easily reboot back to 12.0-U8 through the boot menu just by activating it and rebooting. It comes back properly and works as it did as long as you don't update your ZFS flags after the upgrade.

 

[Breit]

So, I updated from 13.0 to 13.0-U1 yesterday and upon reboot SMB access is not possible anymore. I see all the shares, but cannot access them. Some permission issue. Any ideas?

 

[Breit]

Update: Rollback to 13.0 solves the SMB permission issue. Access is working again.

 

[m.grunwald]

I also had a problem with 13.0-U1.
I use an SMB share for my Plex and after updating TrueNAS and rescanning my Plex library about half of my videos were deleted. I tried to play back the affected videos directly, but that did not work either. The movies themselves didn't seem to be the problem since rolling back to 13.0 solved it.
I didn't have the time to dig into this any further because I wanted to get my Plex library back up. But upon reading other posts here something seems to be off regarding SMB shares in 13.0-U1

 

[AlexTheTrue]

Sadly i had to rollback to 13.0 also. Some Folders were unaccessible, and some files, mostly .docx. No time to research the error yet.

 

[cobrakiller58]

Sadly i had to rollback to 13.0 also. Some Folders were unaccessible, and some files, mostly .docx. No time to research the error yet.

If you happen to remember one of the folders that was inaccessible can you please check if it had an ownership of Root/Wheel?

 

[anodos]

If you happen to remember one of the folders that was inaccessible can you please check if it had an ownership of Root/Wheel?

It's also worth checking samba authentication log to make sure that the client is authenticating as correct user midclt call smb.status AUTH_LOG | jq

 

[AlexTheTrue]

If you happen to remember one of the folders that was inaccessible can you please check if it had an ownership of Root/Wheel?

Yes i think that could be the problem. Mostly i always did "Select a preset ACL" > "OPEN", left owner@ and group@ at default, and just edited the third entry "User" with my username and Permissions-Full Control. The problematic dataset had User myusername instead of root as the user who controls the dataset (File Information - User).

 

[AlexTheTrue]

After i changed the ACL of every dataset to owner root group wheel, all files seem to work again for my SMB user.
Thank you for the hint, @cobra.

 

[Breit]

The owner of a dataset that is shared over Samba always has to be root:wheel starting from 13.0-U1 onwards? Does that also include child datasets? This is not mentioned anywhere and definitely has worked before without root:wheel as owner.
I'll give it a go and report back.

 

[indy]

The owner of a dataset that is shared over Samba always has to be root:wheel starting from 13.0-U1 onwards?

Well I changed every dataset *from* root/wheel to a different user/group, after which I could access shares again.
Seems like just reapplying ACLs could be enough.

Truenas 13 made the switch from directory-based extended attributes (xattr=on) to system-attribute-based extended attributes (xattr=sa).
Maybe there is a problem with the implementation.

Additionally Truenas 12 should be unable to read extended attributes created under Truenas 13... a note for anyone switching back.

 

[Breit]

OK, that took a while. I redid every ACL on every share. Just

Code:

chown root:wheel

on each dataset did not help! A few of them already had that. I might have missed a few special permissions on some folders, but for the most part everything is accessable again. Thanks for the hints.

 

[hba]

Had the same problem. Deleted all entries in the ACL-list (under Edit Filesystem ACL). Marked User and Group and
Apply permissions recursively under advanced. Selected Home ACL and saved and had access again.
One detail though; Mapping the drive now only works with NetBIOS names, not the IP-address.

 

[mistermanko]

Ok a short heads-up would be in order:

What should one do prior updating to U1? disturbing smb access is a no-go for a major "stable" update.

 

[Breit]

Mapping the drive now only works with NetBIOS names, not the IP-address.

This probably is unrelated to the update or even TrueNAS itself.
For me this still works fine, just tested it under Win10.

 

[hba]

This probably is unrelated to the update or even TrueNAS itself.
For me this still works fine, just tested it under Win10.

It worked before updating TN

 

[kn51]

Ok a short heads-up would be in order:

What should one do prior updating to U1? disturbing smb access is a no-go for a major "stable" update.

I did nothing prior, just did an upgrade from the gui. It went quick, everything works...my SMB share including being mapped via IP, jails, plugins, and a VM I have. Then proceeded to update a few jails without issue.

I was a bit surprised how well it went to be honest.

 

[cobrakiller58]

It's also worth checking samba authentication log to make sure that the client is authenticating as correct user midclt call smb.status AUTH_LOG | jq

Has anyone opened a bug report for this potential issue?