パーティションがecryptfsを介して暗号化されているサーバーで次のエラーが発生します。
[3440851.003561] Valid eCryptfs headers not found in file header region or xattr region, inode 22545087
[3440830.026081] Valid eCryptfs headers not found in file header region or xattr region, inode 22553905
以下の暗号化されたパーティションとext4パーティションをアンマウントした後、fsck
を実行すると、次の結果が得られました。
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sda3: clean, 65092/72302592 files, 54219978/289200384 blocks
私は何が起こるかを理解するのに少し無知です。複数のインスタンスで同じセットアップを使用しており、そのうちの1つでのみこれを観察しています。
解決策は、基盤となるディスクを変更することかもしれません!しかし、最終的にはそのような事件を発見して防止するために、何が起こっているのかを理解したいと思います。
システムが正常にシャットダウンされなかったときにこれが発生するのを見ました。特に、暗号化されたデータが、ホストとUSBデバイス間の接続が少し信頼できないUSBデバイスに保存されたときに発生するのを見てきました。しかし、ファイルの書き込み中に他の非クリーンなシャットダウンが発生する可能性もあると思います。
answer by Giovanni で提案されているように、iノードで検索すると、問題のあるファイルを見つけることができます。 ecryptfsは基礎となるファイルシステムのiノード番号を保持するため、そのコマンドを使用して、ファイルへの暗号化されたパスと暗号化されていないパスの両方を見つけることができます。
この方法で基になるファイルシステム上のファイルを検索することは、ecryptfsファイルシステムを検索するよりも大幅に高速です。 1つのシステムでの私の測定では、コールドキャッシュを使用した場合は2つのシステム間で8倍、ホットキャッシュを使用した場合は350倍の速度低下が見られました。
そのオーバーヘッドのため、最初に基盤となるファイルシステムで暗号化されたファイルを見つけることをお勧めします。たとえば、Ubuntuシステムのデフォルト構成では、次のコマンドを使用できます。
find /home/.ecryptfs -inum 22545087
これにより、暗号化されたファイルへのパスが検出されます。これには、ファイルが検出されたホームディレクトリの名前が含まれます。次に、暗号化されていないファイル名を検索するときに、検索を1つのホームディレクトリのみにすぐに制限できます。
find /home/username -inum 22545087
ユーザーが非常に多くのファイルを持っているためにこれが遅すぎる場合は、iノード番号を利用して一度に1つのディレクトリレベルを検索できます。たとえば、暗号化されたファイル名が
/home/.ecryptfs/username/.Private/ECRYPTFS_FNEK_ENCRYPTED.AAAAAA/ECRYPTFS_FNEK_ENCRYPTED.BBBBBB/ECRYPTFS_FNEK_ENCRYPTED.CCCCCC
あなたは最初に実行することができます
ls -i /home/.ecryptfs/username/.Private/ECRYPTFS_FNEK_ENCRYPTED.AAAAAA
これにより、最も外側のディレクトリのiノード番号がわかります。次に、そのディレクトリ名の暗号化されていないバージョンを検索できます。
ls -i /home/username | grep $INODE_NUMBER_FROM_LS
ディレクトリ階層の各レベルでこれを繰り返すと、そのホームディレクトリ内のすべてのファイル名を復号化するために必要なCPU時間を使用せずに、暗号化されていないパスを取得できます。
次の方法で、これを引き起こしているファイルを見つけます。
find / -inum <inode number>
おそらく切り捨てられたファイルが見つかるでしょう。それがecryptfsがその警告を発している理由です。
Catを使用してファイルを読み取り、rmして警告を修正してください。