QuTSでは、ユーザーがスナップショットを取得したり、zfs receiveでスナップショットを受信することが現在可能です。ユーザーはこれをうっかり実行してしまう可能性があり、警告もありません。その結果、クリーンアップできないイミュータブルなスナップショットが作成され、共有全体を削除するか、デバイス全体を消去して再初期化しない限り（データセットがUIで認識されていない場合）、削除できません。
サポートがこれらの状況を修正しないため、zfs CLIコマンドを完全に無効化するか、ユーザーに「デバイスを完全にリセットしない限り永久的なスナップショットが作成される可能性がある」と警告することを強く推奨します。
CLIコマンドでスナップショットをイミュータブル（変更不可）にするかどうかを設定するパラメータはありますか？
@johnsmallberries、QTS（およびQuTS）はWeb UIを通じて使用するよう設計されています。
CLI経由で操作する場合、警告は不要です。ベンダーが提供するUIを回避することによるリスクはご自身で受け入れることになります。
その方針はどこに書かれていますか？
すべてのスナップショットが不変というわけではありません。QuTSはすべての削除操作をインターセプトします。スナップショットであれば削除できません。彼らは、すべての操作が通過するLSM（レイヤード・セキュリティ・モジュール）を追加しています（私の知る限り）。物理的にデバイスにアクセスできることを証明できたとしても、これを無効にすることはできません。
それが方針だと主張したことはありません、あなたの思い込みです。
これ以上お力になれることはないと思います。幸運を祈ります。
しかし、UIを使う場合はそうではありません。
なぜあなたがこれにCLIを使うことにこだわるのか、私にはまだ分かりません。スケジュールを設定してスナップショットを作成し、それで終わりにしましょう。
今は、不変スナップショットを防ぐコマンドフラグなどがあるべきだという点には同意します。しかし、与えられたツールを意図された通りに使いましょう。それでも、持っている唯一の道具がハンマーなら、すべてが釘に見えるのでしょう。
ありがとうございます。UIの使用には全く問題ありません。私はQNAPは初めてで、アプライアンスがZFSベースなので基本的なzfsコマンドが使えると思っていました。CLIやカスタマイズにも段階があることは理解しています。カーネルドライバを書くようなことをすれば完全に自己責任になるのは明らかですが、zfs snapshotは“rm”コマンドのような比較的基本的なコマンドです。QNAPがその動作を変更してクリーンアップできないようにしているとは思いませんでした。確かに、UIではできないzfs send/receiveも人によっては必要かもしれませんが、それについては別のアプライアンスを検討すべきだと今は理解しています。
この件から気分転換しようとした際、プールをエクスポートして通常のopenzfsシステムにインポートできなかったのも驚きでした。予想外でした。ファイルを“削除”しようとするあらゆる手段が塞がれているように感じました。全てのスナップショットが不変であることにも価値はあると思いますが、物理的にデバイスにアクセスできることを証明できれば、メンテナンスモードやLSMのないマシンにドライブを接続するなどして、スナップショットを削除できる方法があれば良いのにと思います。
Immutableスナップショット（イミュータブル・スナップショット）はQuTS Hero 6.0で新しく導入されたものです。ですので、バグレポートを提出してQNAPに知らせることをお勧めします。もしかしたら、これは彼らの意図ではないかもしれません。UI上でスナップショットを作成する際にイミュータビリティ（変更不可）を選択できることは知っています。とはいえ、UIがOS上で何らかのコマンドを実行する必要があるため、可変（ミュータブル）なスナップショット用のCLIコマンドもほぼ確実に存在するはずです。
プールを他のZFSシステムにインポートまたはエクスポートすることについては、うまくいかないのも驚きません。QNAPは独自の方法で構成されており、QuTS Hero内のすべてのパーティションがZFSパーティションというわけでもありません。標準的なLinuxシステムよりも内部構造はやや複雑です。
QNAPの価値はOSや機能セット、アプリなどにあります。本気でLinuxベースの大容量ストレージデバイスを作成し、100% CLIで操作したいのであれば、コスト面でも自分で筐体を購入し、RAIDコントローラーを搭載して運用した方がはるかに有利です。i9 Ultra PCは$1500〜$2000で購入できますが、i9 QNAPは$3000以上し、おそらくi9 Mobileプロセッサを使用しています。
現在の挙動が望ましい場合もあるので、報告すべきかどうか分かりません。ただ、ユーザーが意図せずそのような状況に陥る可能性があると思うので、警告があれば十分かもしれません。おっしゃる通り、「イミュータビリティ（immutability）」は6.0で新しく導入された機能なので少し混乱しやすいです。私が言及しているのは、自分で作成したスナップショットのことで、5.xでも作成方法によってはイミュータブルにできるため、やはり警告があった方がいいかもしれません。もし事前に知っていれば、コマンドをいじったりしなかったと思います。/sys/kernel/security/lsm を cat すると、「qlsm」というものがあり、これはどんな zfs 操作の前にも介在して、CLI上でスナップショットの削除を防ぎます。ですので、事後ではなく事前にユーザーに知らせてあげてください……。また、もし物理的にデバイスにアクセスできる場合、一時的に qlsm を無効化できる「機能」があれば便利かもしれません。誰も「touch filename」した後に「rm filename」できなくなるのは望んでいません——スナップショットはそれとは少し違いますが、似たような考え方です。
QuTS Hero 5.xでは、スナップショットはイミュータブル（不変）ボリュームに保存されている場合のみイミュータブルになりますが、スナップショットは通常のボリューム領域には保存されないため、どのようにしてイミュータブルなスナップショットを作成するのかは分かりません。
CLIでスナップショットを作成する人はほとんどいないので、コマンドラインにオプションを用意することを考えなかったのでしょう。バグや機能要望として報告することをお勧めします。
私はSophosファイアウォールが、クリアなシェルを提供する前にユーザー契約書に「署名／同意」させることを知っています。QNAPも同じことができるかもしれません。
ここから先は自己責任で Y/N
それでも、CLI経由でスナップショットをトリガーしたい場合はqcliを試してみるべきだと思います。
qcli_volumesnapshot については問題ありません。これは他の QNAP 関連の処理と一緒にスナップショットを作成します。ただ、zfs snapshot はフォルダを削除するか再初期化しない限りスナップショットが永久に残るので、警告を表示するか、QNAP が手動スナップショットを削除する「何らかの」方法を提供するべきかもしれません。現在、手動でデータセットの作成と削除はできますが、スナップショットの削除はできません。
あるいは警告を出さない場合でも、他に影響がなければ、メンテナンスモードで「qlsm」LSM を無効化してスナップショットを削除できるようにすると便利だと思います。ランサムウェア対策のために永久スナップショットが必要なのは理解していますが、たとえばメンテナンスモードで再起動するなど、物理的にデバイスにアクセスできることを証明できれば、CLI から簡単に誤って作成してしまう手動スナップショットをクリーンアップできるようにすべきです。
では、qcli_volumesnapshot（qcli_volumesnapshot）が使うべきもののようですね…
貴重なご意見をいただき、誠にありがとうございます。皆様からのご意見は、製品の改善に大変役立っております。ご提案は関係部署に伝え、今後の検討材料とさせていただきます。改めてご支援に感謝申し上げます。