NetworkManagerのアップグレード後に静的ルートが消える場合、そのルートが、現在アクティブな接続ではなくなったプロファイルや設定経路に属していた可能性があります。
ZimaSpaceやLinuxホームサーバーでは、IoT VLAN、バックアップサブネット、またはセカンダリルーターへのルートを、ip routeで手動追加したり、古い接続プロファイルに保存したり、アップグレード後にNetworkManagerが置き換えるプロファイルに関連付けたりしている場合があります。適切な検証方法は、再起動のたびにコマンドを再実行することではなく、現在有効なルートと、アクティブな永続プロファイルを比較することです。
ルートが本当に永続化されていたか確認する
ip routeで追加したルートと、それを再作成するはずのNetworkManager接続プロファイルを比較します。
永続的な静的ルートは接続プロファイルに設定することを説明する、実践的で焦点を絞ったnetworkmanagerガイドは、基盤となるプロトコルを定義するだけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
ルートがカーネルのルーティングテーブルにしか存在しない場合は、アップグレードを原因と決めつける前に、管理対象プロファイルへ移します。
アップグレードによってプロファイルが変更されていないか調べる
パッケージのアップグレード前後で、プロファイル名、UUID、自動接続の状態、ルートエントリを比較します。
NetworkManagerの状態が変わると静的ルートが消えることがあるというトラブルシューティング事例は、基盤となるプロトコルを定義するだけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
アクティブな永続プロファイルにルートを復元し、比較用に以前のプロファイルのコピーを保管します。
NetworkManagerはプロファイル中心で動作することを理解する
1つのインターフェースに複数の保存済みプロファイルを設定できますが、ルート設定を反映するのは、アクティブ化されたプロファイルだけです。
NetworkManagerの設定は接続プロファイルを中心に構成されることを解説する、焦点を絞ったnetworkmanager技術ブログは、基盤となるプロトコルを定義するだけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
見慣れたファイル名を適当に編集するのではなく、UUIDでアクティブなプロファイルを特定します。
ルーティングテーブルとポリシールールを併せて確認する
ルートが別のテーブルに残っていても、そのテーブルを選択していたルールが変更されている可能性があります。
ポリシールーティングではテーブルとルールの両方を使用することを説明する、焦点を絞ったLinuxルーティング解説は、基盤となるプロトコルを定義するだけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
mainに重複ルートを追加する前に、ip ruleと関連するすべてのテーブルを一覧表示します。
ルートメトリックによって経路の選択結果が変わっていないか確認する
同じ宛先をカバーするルートが2つある場合、実効メトリックが低いルートや、より具体的なルートによって、想定していた経路が置き換えられることがあります。
ルートメトリックによって選択される経路が変わることを説明する、焦点を絞ったLinuxネットワーキングチュートリアルは、基盤となるプロトコルを定義するだけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
更新後に宛先プレフィックス、メトリック、インターフェースを比較します。通信が別のルートを使用しているというだけで、ルートが削除されたと判断しないでください。
サーバーのネットワーク設定を1つの管理方式に統一する
従来のスクリプト、手動コマンド、Netplan、NetworkManagerのプロファイルを混在させると、アップグレード時に設定の所有権が競合しやすくなります。
サーバーの経路は1つのNetworkManagerプロファイルで管理することを説明する、実践的で焦点を絞ったLinuxネットワーキングガイドは、基盤となるプロトコルを定義するだけでなく、同じ小さな問題を扱っているため、この分岐の切り分けに役立ちます。
ルートを1つの管理対象プロファイルに統一し、2回再起動して、毎回同じルートとメトリックが戻ることを確認します。
ホームサーバーで実際に使用する経路を再テストする
1つの変数を変更したら、別の経路を使う可能性がある別のテストへ切り替えず、同じクライアントから同じNASまたはセルフホスト環境のワークフローを繰り返します。
関連するホームサーバーのネットワーク経路を扱うZimaSpaceガイドは、最終確認を同じセルフホスト環境に結び付けるのに役立ちます。
再接続、サービスの再起動、さらに2回目の制御された転送またはリクエストの後も、元の症状が解消されたままの場合にのみ、修正は完了です。
よくある質問
なぜip route addは再起動するまで動作するのですか?
ライブのカーネルルーティングテーブルは変更しますが、NetworkManagerの永続的な設定を作成するとは限らないためです。
ルートが残っていても、間違ったテーブルを使用することはありますか?
はい。ポリシールーティングではルートが別のテーブルに配置されることがあり、その場合は対応するルールが必要です。
アップグレード後に接続ファイルを手動で編集すべきですか?
キーファイルを直接管理する明確な理由がない限り、nmcliまたはプラットフォームでサポートされている管理ツールを使用してください。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

