Я получаю следующую ошибку на сервере, где раздел зашифрован с помощью 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
Я немного не понимаю, что случилось. Мы используем одну и ту же настройку на нескольких экземплярах и наблюдаем это только на одном из них.
Решением может быть замена нижележащих дисков! Но я хотел бы понять, что происходит, чтобы в конечном итоге обнаружить и предотвратить подобные инциденты.
Я видел, как это происходило, когда система не была отключена чисто. В частности, я видел, как это происходило, когда зашифрованные данные хранились на USB-устройстве, где соединение между хостом и USB-устройством было немного ненадежным. Но я считаю, что это также может быть вызвано другими нечистыми отключениями во время записи файлов.
Поиск по inode, как предложено в ответ по Джованни действительно может быть использован для поиска проблемного файла. Поскольку ecryptfs сохраняет номера inode базовой файловой системы, эту команду можно использовать для поиска как зашифрованного, так и незашифрованного пути к файлу.
Поиск файла в базовой файловой системе таким способом значительно быстрее, чем поиск в файловой системе ecryptfs. Мои измерения на одной системе показали замедление в 8 раз между двумя системами с холодными кэшами и в 350 раз - с разницей в горячих кэшах.
Из-за этих накладных расходов я предлагаю вам сначала найти зашифрованный файл в базовой файловой системе. Например, в конфигурации по умолчанию в системе Ubuntu можно использовать эту команду:
find /home/.ecryptfs -inum 22545087
Это должно найти путь к зашифрованному файлу, который включает имя домашнего каталога, в котором он был найден. Затем при поиске незашифрованного имени файла вы можете сразу ограничить поиск только одним домашним каталогом:
find /home/username -inum 22545087
Если у пользователя так много файлов, что это слишком медленно, вы можете воспользоваться номерами inode для поиска одного уровня каталога за раз. Например, если имя зашифрованного файла было
/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
Это даст вам номер inode самого внешнего каталога. Затем вы можете найти незашифрованную версию этого имени каталога:
ls -i /home/username | grep $INODE_NUMBER_FROM_LS
Вы можете повторить это для каждого уровня в иерархии каталогов, чтобы получить незашифрованный путь, не используя столько процессорного времени, сколько требуется для расшифровки каждого отдельного имени файла в этом домашнем каталоге.
Узнайте, какой файл вызывает это, с помощью:
find / -inum <inode number>
Вы, вероятно, найдете усеченный файл, и поэтому ecryptfs выдает это предупреждение.
Попробуйте прочитать файл с помощью cat и rm, чтобы исправить предупреждение.