QuTS hero h6.0 ベータテストの問題 - Container Station がコンテナフォルダを受け付けない

概要

Container Stationでコンテナストレージ用のカスタムディレクトリを選択しようとすると、**「コンテナフォルダーの変更に失敗しました」**というエラーが繰り返し表示されました。フォルダーの再作成、パーミッション修正、ZFSデータセットの再構築、Container Stationの再インストールを行っても、エラーは解消しませんでした。

根本原因

QuTS heroはContainer Stationのストレージパスに対して厳格なバリデーションルールを適用しています:

  • フォルダーはQTSの共有フォルダーでなければならず、/share配下に手動で作成したディレクトリは使用できません。
  • **「Container」**という名前は予約されており、共有フォルダーやデータセット名として使用できません。
  • CLIで手動作成したZFSデータセットはQTSの内部設定に登録されないため、Container Stationで拒否されます。
  • Container Stationは**「コントロールパネル → 共有フォルダー」**から作成したフォルダーのみ受け付けます。

解決方法

  • GUIから予約語以外の名前(ContainerData)で新しい共有フォルダーを作成しました。
  • Container Stationのストレージ設定でこの共有フォルダーを直接選択しました。
  • 正しく登録された共有フォルダーであれば、Container Stationは即座にフォルダーを受け付けました。

2. QVPN UPnPポートフォワーディングエラー(PPTP, OpenVPN, QBelt)

概要

UPnPステータスは混在した結果を示し、TCPサービスは正しく転送されましたが、いくつかのVPNサービス(PPTP, OpenVPN, QBelt)はUPnPポートマッピングに一貫して失敗しました。L2TP/IPSecのみが成功しました。

根本原因

パターンから以下が判明しました:

  • UDPポートが失敗し、TCPポートは成功していました。
  • QBeltはUDP 443を使用しており、このポートはルーターやISPによってブロックまたは予約されていることが多いです。
  • 一部のルーターはUDPマッピングのUPnPに対応していません。
  • 二重NATや、低番号UDPポートに対するISPの制限の可能性があります。

解決方法

  • QBeltのポートを高い未使用UDPポート(60000)に変更し、ルーターやISPのフィルタリングを回避しました。
  • ルーターでポートを手動で転送(UDP 60000 → NAS_IP)しました。
  • QVPNサービスを再起動しました。
  • 高番号UDPポートに切り替えたことで、QBeltや他のVPNサービスも正常に動作するようになりました。

3. QuTS heroにおけるZFSデータセットの挙動

概要

手動で作成したZFSデータセットは正しくマウントされましたが、Container StationなどのQTSサービスでは認識されませんでした。

根本原因

QuTS heroでは、データセットをGUIから共有フォルダーとして作成する必要があります。そうすることで:

  • QTSの設定に登録される
  • 適切なACLが割り当てられる
  • システムサービスから参照可能になる
  • Container Stationによるバリデーションが行われる

CLIで作成したデータセットはこれらの登録ステップをバイパスします。

解決方法

  • GUIから共有フォルダーとしてデータセットを再作成しました。
  • QTSにマウントポイント、ACL、メタデータの管理を任せました。
  • その後、Container StationやQVPNなどの依存サービスが正しくフォルダーを認識するようになりました。

共有フォルダーは、QuTS HeroとQTSではまったく異なります。これは両オペレーティングシステム間の主な違いの一つです。

QTSで「Container」フォルダーが必要かどうかは分かりませんが、QuTS HeroのContainer Stationは自動的にそれを作成します。これはよく知られている動作です。

あなたのYAMLコードを使えば、NAS上の他のボリュームやフォルダーパスをデータ保存やコンテナによるアクセスなどに利用できます。

UPnP か UDP のどちらを指しているのかご確認いただけますでしょうか。ありがとうございます。

その他のご指摘につきましては、ご意見をいただきありがとうございます。社内チームにてさらに確認させていただきます。

問題を解決した方法を示すスクリーンショットを共有しようとしたのですが、Qsirchを再度有効にした途端、NASが反応しなくなりました。これは以前見たのと全く同じ挙動で、システムに長時間アクセスできなくなります。そのため、NASが回復するまで今はスクリーンショットを取得できません。

安定したら、私が行った手順の詳細を共有します。

説明ありがとうございます ― 納得できました。ただ、私の場合はデモファームウェアがContainerフォルダ自体を作成しなかったようで、もしくは作成に失敗したようです。自動的にシステム上に表示されることはありませんでした。

SSH経由で手動でフォルダを作成してみても、Container Stationはそれを認識しませんでした。唯一うまくいった方法は、別のフォルダ名を作成してContainer Stationにそのパスを指定することでした。

ですので、これはデモファームウェアのバグか、少なくとも最終版のQuTS Heroビルドとは挙動が一貫していないのかもしれません。同じ問題に遭遇した方の参考になればと思い、共有します。

ファームウェアは、Container Station を初めて起動するまでフォルダを作成しません。その後に作成されます。あなたがすべきことは、自分で作成したものをすべて削除して、最初からやり直すことです。

また、これはデモ用ファームウェアではありません。ベータ版ファームウェアです。大きな違いがあります。

とにかく、最初にContainer Stationを開いたときにフォルダを作成しても動作しません

うーん…なるほど。それはバグのようですね。

これはいつも私に起こることであり、T464にかなりの金額を投資した後に期待されるべきことではありません。サポートチケットを提出した際、何かをインストールするように指示され、それによって私のメディアドライブが壊れてしまいました(ACL 2.0を1週間半以上適用し続けています)。これは本当にひどいです。

安定性や、QNAP NASに期待される普通のパフォーマンスが得られない場合は、別のOSをインストールするつもりです!

あなたはソフトウェアのベータ版をテストしています。これは、正常に動作しない場合があることを意味します。未公開の製品でまだバグが残っているものをこれ以上テストしたくない場合は、hero(ヒーロー)の本番リリース版にダウングレードしてください。それだけで簡単です。

グラスホッパー、、、

もう一度、反応する前に物語の全体の文脈を読んでみてください。

あなたがここに来てハードウェアや会社をけなすだけなら、私は言い続けます。

もう一度言います:あなたはソフトウェアのベータテストをしています。つまり、「修正」が必ずしも機能するとは限りません。リスクを取りたくないなら、ベータテストをしないでください。それだけです。

「いいね!」 1

また、他人のスレッドに全く別の問題で割り込んでくるときに、口を挟まないでください。これもベータテスト中です。製品をけなしたいなら、ここではなく自分のゴミ箱でやってください。

ハイジャック?落ち着けよ。自分を何様だと思ってるんだ?

返信する前にちゃんと読んだらどうだ?ジムで筋肉自慢してる男みたいに見せかけるために返信するんじゃなくてさ。