暗号化された共有フォルダのみでSMBメモリ／CPUクラッシュ — QuTS hero h6.0.1.3500（h5.xからのリグレッション）

English 一般
,
1

モデル：TS-644
ファームウェア：QuTS hero h6.0.1.3500（5.xからアップグレード済み、過去2年間は問題なく稼働）
クライアントOS：macOS Tahoe 26.5.2

問題：暗号化された共有フォルダをSMB経由で閲覧すると、NASのSMBサービスが数秒でCPUとメモリを急激に消費し、続いてシステムログにSMBサービスの再起動エラーが表示されます。クライアント（Finder）はこの際ハングやクラッシュを起こします。

切り分けのために実施したこと：- 同じNAS・同じプール・同じクライアント上の非暗号化SMB共有（大量のファイル/フォルダ数を含む）では、全く問題なく動作し、CPU/メモリの問題も発生しません。- 問題が発生するのはこの暗号化共有フォルダのみで、しかも毎回必ず、閲覧後すぐに再現します。
同じ暗号化フォルダにFile Station（Web GUI）でローカルアクセスした場合は問題なく動作します—つまり暗号・復号自体の問題ではなく、SMBアクセスパスに限定された現象です。

すでに試したが効果のなかった項目：-「カーネルSMBデーモンによるファイル転送の高速化」を無効化-「非同期I/Oを有効にする」を無効化-「大量の小ファイルコピーの高速化」を無効化- 上記3つすべて同時に無効化

影響：この共有は本NASの主目的であり、h6アップグレード前は何年もずっと正常に利用できていました。h6からはサポートされたロールバック手段もなく（ZFSプール/ACLフォーマットがインプレースでアップグレードされるため）、現時点ではSMB経由での回避策が存在しない実質的なブロッカーです。
関連するコミュニティ報告（同じファームウェア系統、同じ症状—macOSクライアントでのSMBメモリ/CPU暴走）：

要望：これは暗号化共有フォルダのSMBパス固有のリグレッションとして扱ってください（一般的なmacOS/SMB問題ではありません）。クリーンな切り分けテストでも再現しており—クライアント、NAS、ファームウェアがすべて同一でも、非暗号化共有には問題がありません。システムログやCPU/メモリスパイク時の画面録画、SSHによるライブデバッグもご要望があれば提供可能です。

2

他の人と同じような状況です――h6アップグレード後、macOSで特定のSMB共有（私の場合は暗号化共有ですが、他の報告を見る限り単一の暗号化場所特有の問題ではないようです）をブラウズすると、数秒でCPU/RAMが確実にスパイクし、SMBサービスの再起動を余儀なくされます。カーネルモードのSMBデーモン無効化、非同期I/O、スモールファイル加速機能の切り替えも試しましたが、どれも効果なし。

現在、一時的に動作確認できた回避策は以下の通りです：

NFSはQuTS hero上でSMBとは完全に独立したサービスなので、SMBパスの不具合を丸ごと回避できます。手順：

  1. コントロールパネル→ネットワークとファイルサービス→Win/Mac/NFS/WebDAV→NFSサービス→有効になっていることを確認（私の環境ではv2とv3対応）。
  2. コントロールパネル→アクセス権限→共有フォルダー→[該当の共有]→共有フォルダー権限の編集→NFSホストアクセス→アクセス権付与、MacのIPアドレス（またはサブネット）を追加、squashは**「no users」**（no_root_squash）を指定、必要に応じて権限を設定。
  3. Macで：Finder→Cmd+K→nfs://<nas-ip>/yourshare→接続。

ターミナル不要で、通常のネットワークドライブのようにマウントされます。根本的な解決にはなりません（QNAPがSMBの不具合を修正する必要があります）が、SMBが使い物にならなくなった状態でも自分は安定して利用できています。とりあえず困ったときの臨時策として、チケット対応を待つよりすぐにアクセスが必要な場合は試してみる価値があります。

3

ご報告ありがとうございます！こちらを社内チームに確認のため転送いたします。ありがとうございます！

4

TS-h973axを使っていますが、まったく同じ問題が発生しています。本当に信じられません、企業がソフトウェアの最も重要な部分に対して品質テストを行わずに、そのまま本番環境にリリースするなんて。

AI時代にこんなのはありえません。しっかりしてくれ、QNAP。:expressionless_face:

5

アップデート：問題は解決しました。原因はファイルやフォルダのメタデータが更新されていなかったことのようです。
「共有フォルダー」を設定から開くと、すべてのメタデータの再構築が始まります。非常に大きいフォルダーの場合、ツリー全体をチェックするため、時間がかかります。完了すると、以前フリーズしていた大きなフォルダーも正常に動作するようになります。

QNAPS AI からの追加情報：

QuTSのアップグレード後、SMB共有フォルダーが遅くなったりフリーズしたりし、それぞれ共有フォルダーを手動でリフレッシュすることで問題が解消されたことが分かりました。なぜそうなったのか、リフレッシュ操作が何をしたのかを説明します。

  1. 想定される原因：

    1. ファームウェアのアップグレード後、SMBサービスや共有メタデータのキャッシュ（アクセス制御リスト、マウント状態、属性のキャッシュなど）が不整合になった。

    2. ファームウェアの変更によりSMBのI/O経路やログの動作に影響が出て、共有メタデータや状態が再読込されるまで遅延が発生した。（リリースノートには特定条件下でSMBが遅くなる問題の修正が記載されています）

    3. バックグラウンドのタスク（ACL適用や権限インデックス作成）がアップデートで中断され、手動で再開する必要があった。

  2. リフレッシュが効果的だった理由：

    1. コントロールパネル > 権限 > 共有フォルダー > 共有フォルダーで共有フォルダーのリフレッシュを行うと、NASが共有のメタデータ、権限、マウント状態を再評価し、古いキャッシュをクリアして、その共有のSMBハンドラーを再初期化します。

    2. この再初期化でSMBデーモンが内部状態を再構築し、通常の応答速度が回復します。

  3. 推奨手順（非破壊的）：

    1. 最新のQuTSビルドとリリースノートを確認し、必要なホットフィックスを適用する。

    2. コントロールパネル > ネットワーク＆ファイルサービス > Win/Mac/NFSで、一時的にSMBを無効化し、再度有効にしてサービスを再読み込みする。

    3. コントロールパネル > システム > システムログでSMB関連の警告や中断されたバックグラウンドタスクを確認する。

    4. 特定の共有でフリーズが繰り返される場合は、その共有で権限リフレッシュを行い、ストレージ＆スナップショットでストレージプール/RAID状態を確認する。

確認：上記の手順後、Mac や Windows クライアントから各SMB共有にアクセスし、ディレクトリのリスト表示や読み書きが正常かどうかを確認してください。ログでSMBエラーが継続して発生していないか監視してください。

複数の共有で問題が続く、または再起動後に再発する場合は、QNAPサービスポータル からチケットを発行し、エンジニアによるログ取得と詳細な診断を依頼してください。

6

だから、最初の投稿を取り下げた方がいいかも？ :smiley:

7

更新：

QNAP SMBサービスバージョン：h4.20.006でも、この挙動は依然として修正されていません。