If you are using the nightly or RC.1 (next week), it is feature complete. It’s best to get Feature requests in ASAP as the window will be closing fairly quickly for Fangtooth.
1 Like
Ok, so, where is the best place to put them?
New topics in the Feature Requests category.
1 Like
Waiting for RC1…
4 Likes
Generally how long in the cycle does it take between RC1 and the full production ready release? Thanks
24.10.0 Stable should be released at October 29th as per published schedule — Software Releases | TrueNAS Documentation Hub
So about a month after RC
3 Likes
thank you
TrueNAS 24.10-RC.1 announcement: https://forums.truenas.com/t/truenas-24-10-rc-1-is-now-available/14641
1 Like
You have to define “full production ready”. For me, that’s the “Conservative” version. If you look at:
and you follow it, generally, that’s the .2 version. So, that would be 24.10.2, and that’s possibly close to year end. I like my machines always running, not messing around with it. Ymmv.
2 Likes
FWIW, I seem to have found an issue between EE 24.10RC1 and MacOS Sequoia 15.0 over SMB where a very small cohort of files become unreadable. (i.e. about 1 in 10,000)
Carbon Copy Cloner reports that their file names are too long but that error is non-sensical as the relevant files have shorter names than other files in the same directories with longer file names.
Revealing the files in Finder results in files that cannot be opened. Renaming said files results in files that sometimes can be opened, sometimes not. Reverting back to Dragonfish 24.04.2 makes all these issues go away.
Jira report submitted.
I’m going to need precise reproduction details in your ticket that don’t rely on CCC if you want it to be actionable. One example of your file names in another forum thread contains an invalid NTFS character and so this is unlikely to be a regression in EE.
1 Like
I am now comparing the two file systems side by side using shells in both NAS.
At the ZFS CLI level, the two file systems are in violent agreement. It is how SMB is presenting them to my MacOS that appears to be broken. I assure you that I didn’t make any mangling changes between EE and Dragonfish because I don’t even remember how to do that anymore, if I did at some point.
The only thing I see in SMB services is “enable Apple SMB2/3 Protocol Extensions”, which is on. When I look under Dataset “Edit SMB” I see there is a Legacy AFP Compatibility Box which is off, and a “Use Apple Style Character-Set Encoding”, which is also off. I presume the latter should be “ON”?
I assure you that I didn’t touch ANY of these settings when I switched to EE.
@winnielinnie for the win! To avoid these issues with MacOS SMB clients, Apple-Style Character Encoding has to be set to “on”.
However, one cannot set that property unless one changes the “Purpose” of the SMB Data Share from “Default Share Parameters” to "Multi-Protocol" or “No Presets” (thank you @awalkerix for correction). See Shares in UI then navigate through each dataset to change these parameters.
I never changed any of these parameters when switching from CORE to SCALE or Dragonfish to EE.
1 Like
Its logged as:
https://ixsystems.atlassian.net/browse/NAS-131653
No. That’s incorrect. You simply select “No presets”. This is NOT required for MacOS SMB clients and should ONLY be set when data has already been written to the share in this way (with invalid NTFS characters on-disk). Changing the character encoding on existing data may render it inaccessible to clients or cause undefined behavior. Please be careful about giving explicit guidance to users before the issue has been investigated as you can inadvertently cause significant problems for other users who follow this as a solution to a perceived problem.
Generally, MacOS clients will map invalid NTFS characters to unicode private range characters defined in services for mac / services for unix standards (old MS compatibility standards) over the wire. Our normal behavior is to write what we receive over wire as-is (no mapping).
Andrew, you keep missing the point that Apple charset compatibility had been enabled on the datasets in that pool for over four years yet became un-enabled when I switched the NAS from Dragonfish to EE Beta or EE RC1. For whatever reason, the same issue did not strike my Time Machine datasets, only the general purpose SMB ones.
You asked for a way to reproduce the problem over on jira, and I submitted a potential avenue to reproduce the behavior I observed.
How about we start there?
This could be as simple as Core-built pools not importing feature flags like Apple compatibility or general purpose SMB presets correctly into Electric Eel.
3 Likes
Alternatively, EE may be having issues with Share Purpose and may be assigning Default by default to any share purpose that isn’t a Time Machine share that made it’s way from FreeNAS to TrueNAS CORE 13 to Dragonfish and then Electric Eel.
It is entirely possible that the Legacy flag should also be set since these shares conceivably have been around since the time that I ran a AFP-only FreeNAS here. Is there any way to detect that history in todays configuration file?
I’d suggest reporting a bug and passing us the nas ticket id.
1 Like
1 Like