Вопросы Теги

Ошибки заголовков eCryptfs

Я получаю следующую ошибку на сервере, где раздел зашифрован с помощью 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

Я немного не понимаю, что произошло. Мы используем одну и ту же настройку на нескольких экземплярах и наблюдаем это только на одном из них.

Решением может быть замена базовых дисков! Но я хотел бы понять, что происходит, чтобы в конечном итоге обнаружить и предотвратить подобные инциденты.

3
задан 23 December 2015 в 13:10
2 ответа

Узнайте, какой файл вызывает это, с помощью: 

find / -inum <inode number>

Вы, вероятно, найдете усеченный файл, и поэтому ecryptfs вызывает это предупреждение.

Попробуйте прочитать файл с помощью cat и rm, чтобы исправить предупреждение.

1
ответ дан 3 December 2019 в 06:30

Я видел, как это происходило, когда система не отключалась чисто. В частности, я видел, как это происходило, когда зашифрованные данные хранились на USB-устройстве, где соединение между хостом и USB-устройством было немного ненадежным. Но я считаю, что и другие нечистые выключения во время записи файлов могут вызвать это.

Поиск по коду, как предложено в ответе answer by Giovanni, действительно может быть использован для поиска проблемного файла. Так как ecryptfs сохраняет номера inode базовой файловой системы, эта команда может быть использована для поиска как зашифрованного, так и незашифрованного пути к файлу.

Поиск файла в базовой файловой системе таким образом значительно быстрее, чем поиск через файловую систему ecryptfs. Мои измерения на одной системе показали замедление в 8 раз между ними с холодным кэшем и в 350 раз с горячим кэшем

Из-за этих накладных расходов я предлагаю вам сначала найти зашифрованный файл в базовой файловой системе. Например, в конфигурации по умолчанию на системе Ubuntu эта команда может быть использована:

find /home/.ecryptfs -inum 22545087

Это должно найти путь к зашифрованному файлу, который включает в себя имя домашнего каталога, в котором он был найден. Тогда при поиске незашифрованного имени файла можно сразу же ограничить поиск только одним домашним каталогом:

find /home/username -inum 22545087

Если у пользователя столько файлов, что это слишком медленно, можно воспользоваться номерами в коде для поиска по одному уровню каталога за раз. Например, если зашифрованное имя файла было

/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

Это даст вам код номера самого внешнего каталога. Затем вы можете просмотреть незашифрованную версию этого имени каталога:

ls -i /home/username | grep $INODE_NUMBER_FROM_LS

Вы можете повторить это для каждого уровня иерархии каталогов, чтобы получить незашифрованный путь без необходимости использовать столько процессорного времени, сколько требуется для расшифровки каждого отдельного имени файла в этом домашнем каталоге.

.
2
ответ дан 3 December 2019 в 06:30

Теги

Похожие вопросы