QNAPeCryptFSファイルシステムの壊れた権限
QNAPデバイスの問題に続いて、データの手動リカバリをすべて手動で行う必要があり、暗号化されたデータのみを取得する必要がありました。
QNAPはこれを行うためにeCryptFSを使用しているようです。パスフレーズを設定できました（ecryptfs-add-passphrase --fnek）そしてファイルシステムをマウントしました：
mount /mnt/md3/.__eN__securedocs/ /mnt/md3/documents/Secure/ -t ecryptfs \
-o rw,ecryptfs_sig=b04b010ba4c32521,ecryptfs_fnek_sig=4f23065f483e5b1c,ecryptfs_unlink_sigs,relatime,ecryptfs_cipher=aes,ecryptfs_key_bytes=32
ファイルは表示されますが、アクセス許可はこれまでに見たことのない状態にあり、ファイルを操作できなくなり、コピーするのに十分ではありません。
[~] # ll /mnt/md3/documents/Secure/
/bin/ls: cannot access /mnt/md3/documents/Secure/battle.net.txt: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Steam.txt: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Work: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Passport Application Declaration.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Bills: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Car: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Receipts: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/.DS_Store: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/._.DS_Store: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/House: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/Banking: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/hmpo_reminder_2016_02_25.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/hmrc_tax_code_2017_2018.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/hmrc_tax_refund_2016_2017_full.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/hmrc_tax_refund_2016_2017.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/2017_11_26_disclosure_scotland_details.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/2017_11_29_disclosure_scotland_basic_disclosure.pdf: No such file or directory
/bin/ls: cannot access /mnt/md3/documents/Secure/passport_scan.pdf: No such file or directory
total 12K
drwxrwxrwx 10 admin administrators 4.0K Feb 13 10:21 ./
drwxrwxrwx 9 admin administrators 4.0K Feb 13 09:53 ../
-????????? ? ? ? ? ? .DS_Store
-????????? ? ? ? ? ? ._.DS_Store
drwxr-xr-x 2 admin administrators 4.0K Apr 9 2017 .digest/
-????????? ? ? ? ? ? 2017_11_26_disclosure_scotland_details.pdf
-????????? ? ? ? ? ? 2017_11_29_disclosure_scotland_basic_disclosure.pdf
d????????? ? ? ? ? ? Banking/
d????????? ? ? ? ? ? Bills/
d????????? ? ? ? ? ? Car/
d????????? ? ? ? ? ? House/
-????????? ? ? ? ? ? Passport Application Declaration.pdf
d????????? ? ? ? ? ? Receipts/
d????????? ? ? ? ? ? Work/
-????????? ? ? ? ? ? battle.net.txt
-????????? ? ? ? ? ? hmpo_reminder_2016_02_25.pdf
-????????? ? ? ? ? ? hmrc_tax_code_2017_2018.pdf
-????????? ? ? ? ? ? hmrc_tax_refund_2016_2017.pdf
-????????? ? ? ? ? ? hmrc_tax_refund_2016_2017_full.pdf
-????????? ? ? ? ? ? passport_scan.pdf
-????????? ? ? ? ? ? Steam.txt
ネット上の他の投稿によると、これは含まれているディレクトリに実行権限がないことが原因ですが、上記のスニペットに示されているように、実行権限が存在するため、これはここでは原因ではありません。
この最後のハードルを克服する方法について何か考えはありますか？
ハードウェアの欠陥が原因で同様の問題が発生しましたが、QNAPになかったため、適用されない可能性があります。
しかし、私は同じ奇妙なls出力を覚えています。
私がしたことは、単にパーティションを読み取り/書き込みとしてマウントし、所有権とアクセス許可の両方を強制することでした。私はそれを2回しなければならなかったことを覚えていますが、理由を思い出せません（おそらく私は何かをタイプミスしました）。
chmod -R a+rwx /mnt/md3/documents/Secure
chown -R admin:administrators /mnt/md3/documents/Secure
ACLにも問題があり、同じように解決しました。
幸いなことに、それはドキュメントパーティションであり、急いでいませんでした。バックアップからの遅い復元を気にすることはできませんでした。
1つのファイルまたは1つのディレクトリで試して、これが当てはまるかどうかを確認できます。
マウントとfsckが正常に機能したとすると、これはデータが使用可能であることを意味します。ただし、マウントされていない暗号化コンテナのバックアップを実行し、可能であれば、コピーをマウントして実験します。
リカバリ後、バックアップディスクですべてのファイルを安全に取得し、QNAPで完全なファクトリリストアを実行します（おそらく、ディスクを削除し、フォーマットして、元に戻すだけで十分です-QNAPはそれらを独自に再初期化する必要があります。Synologyは知っていますおよびTerastoreユニットが行います）、ファイルを元に戻します。これにより、QNAPファイルシステムを再び信頼できることがわかります。
これらのディレクトリには、実行権限がありません。提供した情報によると、ディレクトリをrwおよびroとしてマウントしようとしました。ファイルシステムをrwxとしてマウントする必要があります。ただし、問題は、データ復旧によってファイルシステムのアクセス許可がどのように破壊されたかが原因である可能性があります。
問題を抱えている他の人がWindowsActiveDirectory環境でQNAPを使用しているようです。 このフォーラム投稿 この問題が関係しており、環境がWindows Active Directoryに関連付けられている場合は、少し光を当てる可能性があります。 これは別の投稿です Windowsに関するものです。私も見つけました この投稿 。それらが適用可能かどうかはわかりませんが、問題について検索すると表示されます。
Ecryptfsでは Arch Linux Wiki を、NTFSマウントでは Arch Linux Wiki を参照しています。サブフォルダのアクセス許可に関する QNAP Wiki および データ復旧カテゴリ へのリンクは次のとおりです。これらは、問題のトラブルシューティング方法に関する詳細情報を提供するのにも役立ちます。
ファイルシステムを再マウントし、権限を修正します
最初からやり直します。システムを再起動して再マウントします。以前にmountコマンドが機能してファイルシステムを正常に復号化してマウントできるようにした場合は、ディレクトリのアクセス許可をroot（Sudo）として次のように変更する必要があります。
chmod go= [root directory name]
ラッパーを使用してecryptfsを手動でマウントすることもできます。
ecryptfs-mount-private Path/To/File/System
この場合も、権限が引き続き不足している場合は、この手順の後でchmodが役立つ可能性があります。上記のコマンドを使用して、ecryptfsのマウントパスワードの入力を求められます。
あなたが抱えている追加の問題についてコメントできる場合は、より関連性の高い解決策で回答を更新できます。あなたの問題は、壊れたデータ復旧に関連している可能性があります（解決するには、QNAPがデータ復旧を行うことを推奨する方法に関するガイドに従う必要があります）、または適切なアクセス許可を妨げるNFSまたはNTFSアクセス制御リスト設定に関連している可能性があります。これは、環境がWindowsにも関連付けられている場合にのみ関連する必要があります。誰かが追加する修正があれば、私はそれを大いに感謝します。幸運を祈ります！