ACL Editor まわりは TrueNAS 側の機能としては大きな変更はありませんでしたが、Windows 11 24H2 でゲストアクセス可の共有フォルダにアクセスできなくなったのでそれらの設定が意味なくなってしまいました。
下記は TrueNAS 25.10.1 ベースです。
Dataset を作成して、共有設定するところまでは説明しましたので、あとは、アクセス権のコントールをするため、ありがちなパターンをいくつか説明してみようと思います。
Linux 風のアクセス権コントロール（POSIX）だとユーザーとグループそれぞれ１つずつなので、融通が利かず必要に応じてアクセスコントロール用のグループを作成したりする運用が必要になりますが、 TrueNAS の ACL では、ユーザーやグループを複数設定できるので自由度が高くなっています。
Dataset を SMB用で作成すると基本的に ACL で運用する設定になります。画面の様子を見てる感じでは Strip ACLs を実行したり、 Dataset を General で作成すると旧来の Linux 風のアクセス権コントロールになるみたいです。既存のデータセットで General で作成している場合、 Dataset の Edit で Advanced Options のところに ACL Type という項目があり、 Inherit（継承）とかになっているので、SMB/NTFSv4 に変更することで変えることもできます。なお SMB/NTFSv4 から POSIX に変更するときはアクセス権は変換されないらしいですが、どちらにしても、ACL Type を変更したら適切なアクセス権を Recursively （再帰的）に再度設定し直すべきということのようです。
自由度が高くなった分、機能を濫用して雑に設定すると、ともするとアクセス権が適切についているのか、把握しにくくなったりもするでしょうか。
（ので Use Preset を選んでちょっと調整する、位の運用がいいかと思います）
アクセス権の設定は、
まず Allow Guest Access について説明
Windows 11 24H2 からデフォルトでは無効になりました（グループポリシーなどでも有効にできない）し、
TrueNAS 25.10.1 のGUIでは設定できなくなりましたので、今後は適切なアクセス権を設定する一択になりました。
あとは、 TrueNAS SCALE 上に設定されているユーザーアカウントと同一のアカウント名「User」とかで、パスワードが違う、などという場合もうまくアクセスできません。
その場合は、事前に資格情報マネージャーなどで TrueNAS SCALE にアクセスする用のユーザー名とアカウントを設定するのがいいでしょう。
本筋的には、新しいパソコンを使い始めるときに、User とかで最初から起動するパソコンの場合は、そのまま使い始めず、新しいアカウントを作成（名前の変更ではない）してそれを使うのがいいと思います。
アクセス権の設定は、
Datasets で対象のデータセットを選択して、右側の Permissions か、
Shares で Windows (SMB) Shares の
対象の共有の右側の縦3点から盾型のアイコン Edit Filesystem ACL
■ アクセス制限なし（誰でも読み書き）
冒頭にも書きましたが、この設定はできなくなりましたし、
Windows 11 24H2 側で無効になっています。
■ TrueNASのユーザーとグループでアクセス制限
TrueNAS は Credentials のところでユーザーを作成したり、グループを作成したりできます。
ユーザーを作成する際に自動的にユーザー名と同じグループを作成したり、任意に作成したりしたグループにメンバーを追加したりしてアクセス権を制御します。
● 自分のみ読み書き、他には非公開
（自分専用）
Use Preset
NFS4_RESTRICTED を選択します。
Continue
従来は
Owner に自分、
Owner Group に自分グループを指定してそれぞれ Apply にチェックを入れてSave Access Control List をクリック、でしたが、Owner や Owner Group を変更しないというアプローチができるのでそちらを選択するのがいいケースもあります。
初期設定のアクセス権のまま、
+ Add Item
Who のところで User か Group を選択、
User なら User のところで対象のユーザーを選択して、
下部の Permissions を必要に応じて、
Modify 変更（一般的な読み書き）
から
Read 読み取り専用
Traverse （フォルダの中身は見えなくても、その奥にあるサブフォルダへ通り抜ける許可）
Full Control フルコントロール、従来のオーナー変更の代わりに追加するならコレ
を選択します。
Group の場合も操作は同様です。
これで この共有フォルダにアクセスできるのは自分と、自分グループのメンバーのみとなり、自分グループに自分以外のユーザーを追加しなければ、家族や同僚から覗かれなくなります。
● 自分と、指定したユーザーのみ読み書き、他には非公開
（クローズドなメンバー間）
上記の設定で、
設定した自分グループ（など）にメンバーを追加します。
いくつかやり方はあるけど、
たとえば、
Credentials > Groups
対象のグループをクリックして
Members
追加したいメンバーを左側から選んで > で追加、
右側から選んで < で削除でコントロールします。
Save で保存
または、１つ上の操作と同様に対象のユーザーにも直接アクセス権をつけます。
人数や共有フォルダが増えてくると新しいメンバーや新しい共有フォルダの設定が面倒になったり、設定漏れが発生するので、適切なグループを作成してそれで運用した方がいいとは思います。
● 自分のみ読み書き、他には読み取り専用
（自分が管理者で、他の利用者に提供する。他の利用者はユーザー登録が必要ですが、いちいちグループ指定は不要。ドライバ置き場など）
Use Preset で NFS4_OPEN を選択し、
Owner は自分、Owner Group は自分グループ（誰も追加していないなら）
everyone@ を Read に変更。
この TrueNAS 上にユーザーとして存在している必要はありますが、それだけで読み取り専用でアクセスできるようになります。
※または既存の設定に Add Item で @everyone を Read で追加します。
● 自分と、指定したユーザーのみ読み書き、他の特定のユーザーには読み取り専用
（自分を含む特定のメンバーで管理して…）
Use Preset で NFS4_RESTRICTED を選択し、
Owner 自分ユーザー
Owner Group 自分グループまたは読み書きメンバー用のグループ
として
Add Item をクリックして
Who を Group
Group
で読み取り専用を提供する2つめのグループを指定して
Permissions
をRead
に設定する。
（ユーザーを個別に設定することもできるけど、ちょっと規模が大きくなるとやりきれなくなるので、グループを設定してグループに追加する習慣にしたほうがいいと思います）
@everyone がなければ
2つのグループで読み書きと読み取り専用が制御でき、
それらに属さないユーザーはアクセスできなくなる。
という感じで、とりあえずありそうなパターンを挙げてみましたが、これ以上凝ったことをしたい人は各自で研究するなりしてください。
プリセットだけでなく、
＋Add Item
から認定に項目を追加できるので、好きに設定できます。
TrueNAS 上に作成したユーザーと、Windows で使用しているユーザーアカウントとが同一で、パスワードが一致していると、共有フォルダにアクセスするときにいちいち聞かれないので便利です。
「TrueNASと同一のユーザー名でパスワードの違うアカウント」があると一筋縄ではいかなくなります。（どうしてそんな運用がしたいのかはわかりませんが、メーカー製のプレインストールPCとかを漫然と初期状態のまま使ってると危ないかも）そのような場合は、TrueNAS側の同一のユーザー名をあえて削除して、明確に違うユーザー名を使うようにするか（そうすれば接続時にネットワーク資格情報を訊かれます）、Windows 側で、ユーザー名を変えて作り直す（ユーザー名の変更ではネットワークアクセスしたりするときの資格情報が変わるわけではない）か、Windows側で、資格情報マネージャーを使って、Windows資格情報として、当該のTrueNASへ作成されているユーザーとパスワードを指定する方法でしょうか。資格情報を登録したらパソコンを再起動してから試してみてください。
どうしても再起動せずに反映させたい場合は、
net use * /DELETE
を実行することで、キャッシュされていたアクセス権がリセットされます。
（それでもうまくいかない場合は結局なにはともあれ Windows を再起動）
補足
Apps (Docker) で使用しているDatasetの場合
Docker の永続化目的のフォルダをSMBでも共有するような場合は、既存のアクセス権管理を優先するべきで、既存のアクセス権を示すグループに自分ユーザーを入れる、などの運用をすべきでしょう。
「Ownerを変更しない」アプローチ
Rsync を実行する際、 owner は実行するユーザーでなければならないという制限や、
各ユーザーのホームディレクトリなどは、他のユーザーと共有する前提になっていないので、これらの扱いは既存の設定を破壊しないように気をつける必要があります。