TrueNAS 13.0-U1.1 Planned for July 25th

[morganL]

TrueNAS 13.0-U1 has generally been solid, but there are some annoying SMB issues we would all like addressed.

A hot-fix version TrueNAS 13.0-U1.1 is planned for next Monday and will address about 5 issues we have identified. These include the following SMB issues:

NAS-117070
Upgrade from 13-U1 brakes SMB Permissions

NAS-117071
Shadow Copies In Nested Datasets Not Visible in 13.0-U1 vs 12.0-U8.1

NAS-117213
Can't change permissions on shares on 13.0-U1

If you have any questions, please ask.

 

[Nordlicht-13]

Hopefully it will be possible to install the NextCloud-Plugin again.

 

[morganL]

Hopefully it will be possible to install the NextCloud-Plugin again.

I believe those issues are related to the Plugin... not the base TrueNAS 13.0-U1.

My understanding is this was related to some bugs in upstream FreeBSD 13.1 packages. These have been resolved.

@Nordlicht-13 can you test again... see if the issues persist on your end.

 

[Samuel Tai]

I believe those issues are related to the Plugin... not the base TrueNAS 13.0-U1. I'll try to find resolution and schedule.

@morganL, there a bunch of plugins unable to install because they refer to py38-* libraries instead of the equivalent py39-* libraries, and are failing the pkg install during plugin creation. This includes the official NextCloud plugin.

 

[morganL]

TrueNAS 13.0-U1.1 is being pushed out now. Should be available Now.

 

[jlpellet]

Applied 13U1.1 & installed properly on 5 systems. However, since 13RC1, I have had an ongoing issue on an interaction between SMB & TN OS not properly managing the Windows archive bit, which I use with xcopy in a batch file to determinte which files have changed. Simple, the attrib command from Win7 shell is unable to reliably toggle the archive bit. As a result, 1 server remains on last 12. All of the SMB "fixes" in 13 have not successfully resolved this. I have replciated this bahavior on mult TN system with updates & fresh install. I have documented this in a private conversation with anados supplying documentation & debug. Any suggestions welcome.

 

[anodos]

Applied 13U1.1 & installed properly on 5 systems. However, since 13RC1, I have had an ongoing issue on an interaction between SMB & TN OS not properly managing the Windows archive bit, which I use with xcopy in a batch file to determinte which files have changed. Simple, the attrib command from Win7 shell is unable to reliably toggle the archive bit. As a result, 1 server remains on last 12. All of the SMB "fixes" in 13 have not successfully resolved this. I have replciated this bahavior on mult TN system with updates & fresh install. I have documented this in a private conversation with anados supplying documentation & debug. Any suggestions welcome.

This bugfix contained the issues that I was able to reproduce which were quite serious for affected users. I am still investigating the issue with archive bit, but since Windows 7 is EOL it took the back burner.

 

[jlpellet]

Just to note, the exact same attribute issue is displayed in Windows 10.
john

 

[tineidae]

Hello,

i updated 13.0-U1.1 today, at first everything looked fine, but then Veeam start complaining that all of my nfs based repos are offline. I checked the repo configuration and veeam and it looked good. In Veeam i tried to edit the repo settings but it got stuck for a very long time and then prints "Failed to create file in the specified directory no write access to destination". I did a restart of TrueNAS and our Veeam Server but that didnt solve the issue. The solution that worked for me is to downgrade to 13.0-U1, immedately Veeam reconnected all NFS repos without issues.

Any changes in TrueNAS 13.0-U1.1 that breaks or changes nfs behaviour? the repos in Veeam are all configured as NFS 4.1.

Sven

 

[anodos]

Hello,

i updated 13.0-U1.1 today, at first everything looked fine, but then Veeam start complaining that all of my nfs based repos are offline. I checked the repo configuration and veeam and it looked good. In Veeam i tried to edit the repo settings but it got stuck for a very long time and then prints "Failed to create file in the specified directory no write access to destination". I did a restart of TrueNAS and our Veeam Server but that didnt solve the issue. The solution that worked for me is to downgrade to 13.0-U1, immedately Veeam reconnected all NFS repos without issues.

Any changes in TrueNAS 13.0-U1.1 that breaks or changes nfs behaviour? the repos in Veeam are all configured as NFS 4.1.

Sven

There are no NFS-related changes in 13.0-U1 -> 13.0-U1.1.

 

[tineidae]

There are no NFS-related changes in 13.0-U1 -> 13.0-U1.1.

Thats strange, i gave 13.0-U1.1 another go and the issue immediately came back. For now i downgraded again and plan a bigger maintanance window to do some more investigation and try to get a network dump to see thats happen between Veeam and TrueNAS.

 

[anodos]

Thats strange, i gave 13.0-U1.1 another go and the issue immediately came back. For now i downgraded again and plan a bigger maintanance window to do some more investigation and try to get a network dump to see thats happen between Veeam and TrueNAS.

There are no changes in the OS repo (we use kernel NFS server). One unrelated change in middleware repo. And some samba changes mentioned above.

 

[morganL]

Thats strange, i gave 13.0-U1.1 another go and the issue immediately came back. For now i downgraded again and plan a bigger maintanance window to do some more investigation and try to get a network dump to see thats happen between Veeam and TrueNAS.

If you can reproduce the issue, please report a bug. We'd like to resolve it even if we can't guess what the cause is.