TrueNAS 13.0-U1 has been released

[awasb]

Installed fine. All engines running so far (as it seems).

 

[hervon]

Same. Issue with hard drives not seen with prerealease is gone!

Jails : plex qbittorrent minidlna urbackup all working fine.

SMB and cloud tasks ok too.

 

[jlpellet]

Installed 13U1 on 5 systems yesterday & 4 went well. 1 system would not allow access (copy, delete, open) to fines within 2 of many directories via Windows SMB. Sampled files in other dirs w/o problem. Verified share/share acl/files acl as prev. set. Reverted to 12U8 & all fine. Fixed by 1) del dirs in 12U8, reboot to 13U1, copy dirs fm other source. No access issues. Weird but noted if anyone else has issue.

 

[anodos]

Installed 13U1 on 5 systems yesterday & 4 went well. 1 system would not allow access (copy, delete, open) to fines within 2 of many directories via Windows SMB. Sampled files in other dirs w/o problem. Verified share/share acl/files acl as prev. set. Reverted to 12U8 & all fine. Fixed by 1) del dirs in 12U8, reboot to 13U1, copy dirs fm other source. No access issues. Weird but noted if anyone else has issue.

Can you PM me a debug please? From 13. I need information to be able to fix issues users encounter.

 

[jlpellet]

Sent in separate conversation. Note fix above did not work - seems archive bit reset after minutes.

 

[anodos]

Sent in separate conversation. Note fix above did not work - seems archive bit reset after minutes.

I'm not seeing he archive bit getting reset on my test server. If you can reliably reproduce, I will need to see a packet capture or debug with SMB log level at FULL.

 

[jlpellet]

OK. Note, I have tried to replicate on 2 other 13U1 servers & the issue did not arise. I think the best use of our time is for you to put this on hold & I'll delete the existing shares & recreate, them, if the issue persists, I'll scrub the install & do a fresh 13U1 install & reimport the pool & recreate the shares. Then I'll feed back the results but this will take me a couple of days. Thanks.

 

[anodos]

OK. Note, I have tried to replicate on 2 other 13U1 servers & the issue did not arise. I think the best use of our time is for you to put this on hold & I'll delete the existing shares & recreate, them, if the issue persists, I'll scrub the install & do a fresh 13U1 install & reimport the pool & recreate the shares. Then I'll feed back the results but this will take me a couple of days. Thanks.

I think I figured out a way to tickle the issue using a MacOS client. In this case the archive bit is being toggled concurrently with a ctime change, which means that OS / FS are doing the right thing with regard to the archive bit. It's an open question for now whether it's being toggled because the MacOS client is changing metadata on file (which they sometimes do when simply viewing a file).

Code:

Frame 437: 486 bytes on wire (3888 bits), 486 bytes captured (3888 bits)
Ethernet II, Src: Apple_3c:33:a6 (a8:60:b6:3c:33:a6), Dst: Microsof_00:97:03 (00:15:5d:00:97:03)
Internet Protocol Version 4, Src: 192.168.0.155, Dst: 192.168.0.156
Transmission Control Protocol, Src Port: 56650, Dst Port: 445, Seq: 24091, Ack: 22659, Len: 420
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
    Create Request (0x05)
        StructureSize: 0x0039
        Oplock: No oplock (0x00)
        Impersonation level: Impersonation (2)
        Create Flags: 0x0000000000000000
        Reserved: 0000000000000000
        Access Mask: 0x00100180
        File Attributes: 0x00000080
        Share Access: 0x00000007, Read, Write, Delete
        Disposition: Open (if file exists open it, else fail) (1)
        Create Options: 0x00000000
        Filename: New folder\TESTDOC.docx
        Blob Offset: 0x000000a8
        Blob Length: 24
        ExtraInfo SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST
SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
    SetInfo Request (0x11)
        StructureSize: 0x0021
        Class: FILE_INFO (0x01)
        InfoLevel: SMB2_FILE_BASIC_INFO (0x04)
        Setinfo Size: 40
        Setinfo Offset: 0x0060
        Unknown: 000000000000
        GUID handle
        SMB2_FILE_BASIC_INFO
            Create: No time specified (0)
            Last Access: Jul  6, 2022 10:19:36.000000000 EDT
            Last Write: No time specified (0)
            Last Change: No time specified (0)
            File Attributes: 0x00000080
            Unknown: 00000000
SMB2 (Server Message Block Protocol version 2)
    SMB2 Header
    Close Request (0x06)
        StructureSize: 0x0018
        Close Flags: 0x0000
        GUID handle
TRANSUM RTE Data

edit: The MacOS client decided it was a good idea to manually update the atime on the file. So for the MacOS case, I believe this is correct / expected behavior (archive bit toggled).

 

[anodos]

For a bit more background on this for those unaware, FreeBSD and SCALE (not Linux in general) have native support for the DOS archive bit inside ZFS. This bit is set every time a file's data or metadata is changed. It's a legacy, but still in some circumstances useful feature for Windows backups. The idea is that as your software / scripts backs up files, it unsets the archive flag on them. Only files with the archive bit set are backed up. This allows users to perform file-based backups in a fairly quick manner. Since the flag is implemented at the FS level, it doesn't care whether another service or kernel process changes the file (always does the right thing).

Of course this doesn't do much good if a client decides it's a good idea to manually update atime values.

 

[Volts]

If you don't mind indulging me ... this feels correct, but also maybe insane.

Is it possible to disable this atime -> archive behavior on ZFS?
I assume that disabling atime on the dataset would not help, because Samba will materialize this explicit update to the metadata.

TrueNAS/FreeBSD/ZFS:
Q: Why does atime flip archive? They have orthogonal purposes.
A: ... so updated atime metadata will be backed up, of course!
I suppose this is technically correct: metadata has been updated. But it also defeats any actual (if mythical) productive use of archive, doesn't it?

Windows doesn't flip archive on local filesystems when atime is updated, AFAICT.

macOS:
Why might macOS explicitly push atime like this?
I struggle to call it "technically correct". It just feels extra.
Did you notice when it does this? I'm wondering if mounting the smbfs with -o noatime would be valuable.

 

[anodos]

If you don't mind indulging me ... this feels correct, but also maybe insane.

Is it possible to disable this atime -> archive behavior on ZFS?
I assume that disabling atime on the dataset would not help, because Samba will materialize this explicit update to the metadata.

You misunderstand. This is not the OS/kernel updating atime in normal way. In this case MacOS client is requesting to alter the value of the atime timestamp. Samba converts this request (appropriately) into a utimensat(2) call to update the timestamp. This is considered a change of file metadata and archive is toggled. FWIW, the internal ZFS znode sequence counter is also incremented with this operation. This is correct and expected.

utimensat(2)

www.freebsd.org

Normal operations that cause OS/kernel to increment atime don't affect the archive bit. For instance, reading the file without altering data does not toggle the archive bit.

I suspect that this particular MacOS 11.6 behavior (haven't checked other versions) would do exactly the same thing on a Windows server. As for why it does it, the only available public sources for the MacOS SMB client are quite old and often not a good guide to current-ish behavior. It's sort of like reading tea leaves. I haven't really researched this in depth on the MacOS side, it's just an illustration of how sometimes client implementation details can cause `archive` to be somewhat less than helpful.

 

[Volts]

Thanks, that's what I was asking - since the access time is being explicitly set through SMB, it's not controlled by the filesystem driver's atime-on-read behavior.

It's also not intuitive to me that 0x00000080 (FILE_ATTRIBUTE_NORMAL) is also set, but the end result is +archive.

 

[anodos]

It's also not intuitive to me that 0x00000080 (FILE_ATTRIBUTE_NORMAL) is also set, but the end result is +archive.

That part may be occurring out of order. I can double-check on Monday (will be out for rest of week away from my dev environment).

 

[Clouseau]

Okey - first time ever I have major issues after upgrade - Upgraded from 13-RELEASE to 13.0 U1 and now Web ui does not do anything after giving login details. No visible errors at the boot. Console setup is visible and working but I can't access welcome screen at the boot so that I could revert back to older boot environment. Keyboard is working in Console setup fine but can you change boot environment there? Is there anything doable from shell? (change the boot environment?)

 

[Samuel Tai]

Okey - first time ever I have major issues after upgrade - Upgraded from 13-RELEASE to 13.0 U1 and now Web ui does not do anything after giving login details. No visible errors at the boot. Console setup is visible and working but I can't access welcome screen at the boot so that I could revert back to older boot environment. Keyboard is working in Console setup fine but can you change boot environment there? Is there anything doable from shell? (change the boot environment?)

Try clearing your browser cache.

 

[anodos]

Okey - first time ever I have major issues after upgrade - Upgraded from 13-RELEASE to 13.0 U1 and now Web ui does not do anything after giving login details. No visible errors at the boot. Console setup is visible and working but I can't access welcome screen at the boot so that I could revert back to older boot environment. Keyboard is working in Console setup fine but can you change boot environment there? Is there anything doable from shell? (change the boot environment?)

beadm list will list available boot environments. You can activate a different one via beadm activate. (assuming that clearing browser cache doesn't work).

 

[Matt84]

Now that 13.0-U1 is out I thought I'd upgrade my backup box to test. If this is a U1 release, how come it givers me a warning saying not for production use?