投稿

ラベル(QNAP)が付いた投稿を表示しています

QNAP NAS の RAID 1 ミラーディスクの追加エラー

イメージ
QNAP の NAS(2 ドライブ)を RAID 1(ミラーリング)で運用している。HDD は WD Red 6TB × 2。この NAS が夏の停電時に、古い方のドライブ 1 の HDD でエラーが発生し、ドライブ 2 のみの片肺運転となっていた。 QNAP の GUI 上で操作しても状況が変化しないので、一旦、ドライブ 1 を取り外し、外付け HDD ケースに入れ、Windows PC に接続し、パーティションを全て削除して、単一パーティションを作り、NTFS で完全フォーマットをし直した(完全フォーマットなので丸一日を要した)。Windows 上で S.M.A.R.T. 情報を見る限り、問題は発生していないようである。 QNAP に HDD を戻したが、個別情報でドライブ 1 はステータス「準備完了」、S.M.A.R.T. 情報「良好」となっているものの、論理ボリューム(RAID 1 のミラーリングディスク)としては追加されずに、エラー(Add drive 1 to the volume failed)となった。 HDD を再度 Windows PC に戻して、Windows 上で パーティションを削除してパーティションが存在しない状態にしてから 、QNAP に HDD を戻した。すると今回は、ミラーリングに追加され、フォーマット処理が無事開始した。 QNAP でミラーリング(フォーマット処理含む)が終了後、S.M.A.R.T. の完全テストも行ったが、何のエラーも検出されなかった。元のエラーは何だったのだろうと思うが、多分、QNAP の OS が馬鹿だっただけだろう。 以上、QNAP に HDD を追加する・し直す場合には、追加する HDD はパーティションを削除した状態で追加しなければならないという話. 余談 1:WD Red WD Red シリーズ は元々は CMR 方式だったのだが、後に RAID に不向きな SMR に変更されてしまった( 参考 )。単に Red だからと安易に信用せず、CMR 方式の型番であることを確認して購入した方がよい。 WD 公式ブログのリスト によると、2TB 〜 6TB の EFAX が SMR なので、買ってはいけない型番。一方、8TB 〜 14TB の EFAX

iTunes と macOS Catalina (10.15) と QNAP の問題

イメージ
これまで長い間 QNAP の NAS と Mac を使っていながら、iTunes を使ったことがなかった。自分が全然 iTunes で音楽を聴くというような行動スタイルがなかったからだ。ところが、家族が Mac で NAS に取り込んだ音楽を聴けるようにする要請があり、今さら、QNAP の NAS を iTunes サーバー化してみようかということになった。 元々、QNAP が iTunes にも対応しているということは管理画面でも知っていたが、調べてみると、 たった 1 ページの説明 で済む簡単な作業のようだった。 ところが、iTunes Server を有効化して、macOS (Catalina) のミュージック.app から QNAP 上の iTunes サーバーが見えるようになるまでは簡単にできたのはいいのだが、NAS 上のアルバムを選択しても、再生ができない。調べてみると、macOS Catalina (10.15) から新しくなったミュージック.app の仕様の変更が原因で、古い DAAP( Digital Audio Access Protocol )に対応しなくなったため(プロトコルのメッセージ中の「:」が「@」に変更されているとか)。原因はそれなのだが、悪いのはむしろ、とっくの昔に開発が停止した古い DAAP 用のサーバーアプリ(Firefly)のままで放置している QNAP の怠慢である(同じ台湾メーカーの Synology も似たりよったりな状況らしい)。Firefly の後継の forked-daapd にとっくの昔にリプレースしておくべき話だという。 Docker で forked-daapd を入れる(Docker) そこでどうにかする方法としてネットに出ているのが、 Docker を使って forked-daapd を入れてしまう という方法。ところが、Docker を入れられないモデルの NAS の場合はどうしようもない! そう、うちの QNAP の NAS、 HS-210 がそうだ。ふざけんな QNAP! macOS Catalina に iTunes.app を入れる(Retroactive) 仕方がないので、以前の iTunes.app を入れることで、当面の時間稼ぎをすることにした。 Retr

QNAP の SSH のアクセス元制限の不完全な仕様

OpenVPN で実家の LAN につなぎ、VPN 経由で NAS(QNAP)にアクセスできるようになったので、ネットワークセキュリティを強化すべく、NAS の SSH にアクセス元制限を付けた。/root/.ssh/authorized_keys の公開鍵リストに、from="(ネットワークアドレス)" のオプション設定を追記したわけだ。 ところで、元々ブリッジモードの VPN 設定だったのを、ルーターモードに変更したため、アクセス元のクライアント機のネットワークアドレス(192.168.11.0/24)は NAS 側のネットワークアドレス(192.168.0.0/24)と異なるものとなった。そのため、from にカンマ(「,」)区切りでネットワークアドレスを列挙する必要がある。 from="192.168.0.0/24,192.168.11.0/24" ssh-rsa AAAAB3N... しかし、どうやら QNAP の SSHd では仕様が不完全なようで、from として列挙したものを与えると、正常に動作しない(すべてのネットワークからアクセスできなくなった。仕方なく、一時的に telnet を使って復旧作業をする羽目になった)。 つまり、authorized_keys の from 設定としては列挙で設定することはできず、一種類の設定しか与えることができないのである。 簡単に思い浮ぶのは、VPN をルーターモードで運用するのをやめて、ブリッジモードに戻すことである。そうすれば、クライアント機のネットワークアドレスは NAS 側のネットワークアドレスと同一なので、from のエントリーは一種類で済む。 それでもせっかくルーターモードにしたのにブリッジに戻すのも何となく嫌だったので、(専門家でもないのに独学でネットワークエンジニアの資格をパスしたという“昔取った杵柄”を活用できたのか)ポク・ポク・ポク・チーンと思い付いたのが、ネットワークアドレスに、192.168.0.0/23 という値を使う方法。 23 ビットというネットマスクを使う奇策 である。この設定は、192.168.0.0 〜 192.168.1.255 の範囲の IP を意味するネットワークアドレスである。 from="192.16