TrueNAS SCALE を 25.04.2.4（通称 Electric Eel）にアップデートしたその日、
いつものように「n8n」を開こうとしたら、アプリ一覧から spっと消えていた。
最初は UI の不具合かと思った。
だが調べていくうちに、これは「事件」ではなく「仕様変更」だった。
Kubernetes から Docker への完全移行──
つまり、旧アプリが “置き去り” になる宿命だったのだ。
※インストール手順そのものは以下の記事にまとめています。
👉 TrueNAS × n8nで自動バースデーメールDXを作る
気づき ─ “消えたn8n”
久しぶりに TrueNAS の管理画面を開いた。
仕事のタスク整理を自動化していた n8n（ワークフロー自動化ツール）を触ろうと思い、
いつものように 「Apps」タブを開く。
……ない。
あのピンク色の n8n アイコンが、どこにも見当たらない。
「まさか、バージョンアップで消えるなんてことは……ないよな？」
システム情報を見ると、TrueNAS は 25.04.2.4 “Electric Eel” に上がっていた。
どうやら、これが運命の分岐点だったらしい。
原因 ─ Electric EelとKubernetesの別れ
調べていくうちに、答えはすぐに見つかった。
TrueNAS SCALE 25.04（コードネーム：Electric Eel）では、アプリ基盤が大きく変わったのだ。
これまでTrueNAS SCALEは、アプリをKubernetes（K3s）上のPodとして動かしていた。
だがElectric Eel以降は、DockerベースのApp Container方式に完全移行。
つまり、「Kubernetesで構築されたアプリ」は自動では引き継がれず、
TrueNASの世界では“過去の遺構”として扱われることになった。
アップグレード時、システムは旧アプリを無理に変換せず、
ix-applicationsデータセット内にそのまま保管する。
一見消えたように見えるのは、実際にはUIから外れただけ。
実体はまだプールの奥深くに残っている。
確認には以下のコマンドを使う。
sudo zfs list | grep n8nこれで、旧Kubernetes環境に残っているデータセットが表示されるはずだ。
おそらくあなたのように ix-applications/releases/n8n が並んでいるだろう。
この仕組み自体は、失敗時の安全装置としては正しい。
しかし、アプリが多い環境では「すべてが一斉に孤児化」するため、
“アプリが消えた”ように見える。
そしてn8nのようなDocker互換アプリは、
自力で再構築するのがもっとも早く確実な手段になる。
救出 ─ ZFSで残骸を片付ける
Electric Eel では “Kubernetes時代の亡霊” が確実に残っている。ix-applications/releases/n8n の中を覗くと、volumes や pgData のようなディレクトリが残存しており、これらが新規インストールを妨げる。
手動削除を試みても、「Permission denied」や「Device or resource busy」 に阻まれることが多い。
ステップ1：残骸の確認
まず、ZFSデータセットとしてどこまで残っているか確認する。
sudo zfs list | grep n8n
ix-applications/releases/n8n 以下に、charts や volumes/ix_volumes/pgData などが列挙されていれば、それらが再インストールの妨げとなる。
ステップ2：ZFSでクリーン削除
TrueNASでは、rmコマンドで削除しようとしても権限やZFSロックに阻まれるため、
潔く zfs destroy を使うのが正解だ。
sudo zfs destroy -r HDD1/ix-applications/releases/n8n/volumes/ix_volumes/pgData
sudo zfs destroy -r HDD1/ix-applications/releases/n8n/volumes/ix_volumes/data
sudo zfs destroy -r HDD1/ix-applications/releases/n8n/volumes/ix_volumes/pgBackup
sudo zfs destroy -r HDD1/ix-applications/releases/n8n/volumes/ix_volumes
sudo zfs destroy -r HDD1/ix-applications/releases/n8n/volumes
sudo zfs destroy -r HDD1/ix-applications/releases/n8n/charts
sudo zfs destroy -r HDD1/ix-applications/releases/n8nこの順番で削除していけば、依存関係による “busy” エラーを避けて安全にクリーンアップできる。
ステップ3：再確認
削除完了後にもう一度確認。
sudo zfs list | grep n8nここで何も表示されなければ、見事に「亡霊退治」完了だ。
再生 ─ n8nをDockerで呼び戻す
ZFSの亡霊退治が完了したら、ようやく “再生の儀式” に入る。
Electric Eelでは、すべてのアプリがDockerベースに切り替わっているため、再インストールもシンプルだ。
ステップ1：Appsから再インストール
TrueNASの管理画面に戻り、左メニューの 「Apps」→「Discover Apps」 へ。
一覧の中から n8n（Community版） を選択し、「Install」 をクリックする。
Application Name は 「n8n」 のままで問題ない。
先にZFSで旧データセットを完全削除しているので、名前の競合は発生しない。
ステップ2：設定の基本はデフォルトでOK
ほとんどの項目はデフォルトで構わない。
特に以下の点だけ確認しておこう。
- Storage Type: ixVolume（デフォルト）
- Timezone: Asia/Tokyo
- Security Context: 変更不要（rootで動作可）
設定完了後、右下の 「Install」 をクリック。
数分待てば、n8nコンテナがDockerとして起動し、Apps 一覧に「Active」状態で表示される。
ステップ3：ライセンス再発行の罠
再インストール後にブラウザで n8n にアクセスすると、
初回起動時にライセンス再登録を求められる。
これは “新しいインスタンス” として扱われるため、以前と同じメールアドレスでも再登録が必要だ。
心配無用、重複登録は許可されている。
ステップ4：ワークフローの再構築
旧データはすべて削除したため、以前のワークフローは復元できない。
ただし、n8nの設定UIやノード構造はまったく同じ。
もし以前の記事（TrueNASにn8nを導入して“誕生日メールDX”を自動化する）を参考にしていれば、
同じ手順でわずか数分で再構築可能だ。
この瞬間、n8nは再び息を吹き返した。
Dockerの新世界で、より軽く、より速く。
教訓 ─ Kubernetesの終焉と、主権クラウドの夜明け
Electric Eelは、単なるTrueNASのアップデートではない。
それは、「Kubernetesという夢の終焉」を告げる鐘の音だった。
分散幻想の終焉
Kubernetesは、世界をひとつの巨大クラスタとして扱う思想から生まれた。
「どこでも動く」「誰でもスケールできる」。それはクラウド黎明期の理想であり、
かつてインターネットが約束した“自由”の再来でもあった。
しかし、その理想はやがて「重力を無視した設計」へと変質した。
家庭用NASにPodを並べ、1CPUのリソースでオーケストレーションを回す──。
それは、都市の電力を単三電池でまかなうような無理があった。
Dockerへの回帰＝主権の回復
Electric EelでTrueNASがDockerへ回帰したのは、単なる軽量化のためではない。
それは、「人間が制御できる範囲で自律する」という再定義である。
Dockerはシンプルだ。
起動も停止も、ボリュームの扱いも、目に見える。
それはつまり、「見えるところに責任がある」という主権の回復だ。
TrueNASは、クラスタ幻想から降り、
再びローカルで完結する“現実的なクラウド”を選んだ。
この決断こそ、ポストKubernetes時代の象徴だ。
他社が静かに守り続けた地平
QNAPもSynologyも、最初からこの現実を見据えていた。
彼らは「クラウドに似せたローカル」を志向しながらも、
Dockerという一枚岩の基盤を頑なに手放さなかった。
結果的に、彼らは「安定した進化」を選び、
TrueNASは「壮大な失敗の果てに真理へ帰還した」のである。
そして、“主権クラウド”の夜明けへ
Kubernetesは「スケールの神話」だった。
Dockerは「掌に収まる現実」だ。
そしてTrueNASが今、選んだのは──
自分の手で育て、自分の責任で壊せる自由。
これが、次世代のローカルクラウド、
すなわち 「ソブリンクラウド（主権を持つクラウド）」 の第一歩である。
最後に、あなたが再びn8nを立ち上げたその瞬間。
それは単なるサービス復旧ではなく、
“制御を取り戻した人間” の象徴的行為だったのかもしれない。
