5

У меня есть зашифрованная файловая система Encfs на 200 гигов, живущая в моем Dropbox и доступная нескольким машинам, и у меня никогда не было проблем с этим до сих пор.

Я переместил около 10 гигабайт данных на один (Ubuntu) компьютер X, и через 2 дня, когда синхронизация закончилась на другом (Ubuntu) компьютере Y, возникли некоторые проблемы: некоторые файлы не могут быть прочитаны на Y и дают мне ввод / Ошибки вывода, например

$ file myfile.txt
myfile.txt: ERROR: cannot read `myfile.txt' (Input/output error)

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

У меня также есть система, работающая на компьютере с Windows Z; Я посмотрел на файлы в Z, и я также получил ошибки ввода-вывода (хотя сообщения об ошибках Windows были довольно загадочными). Так что в некотором смысле проблема почти наверняка "в конце X".

Мне удалось перейти к каталогу в фактическом зашифрованном каталоге Dropbox, который соответствует каталогу, в котором происходят ошибки ввода / вывода. Все (зашифрованные) файлы могут быть прочитаны нормально, так что проблема, похоже, не является реальной ошибкой ввода-вывода с физическим диском, проблема, похоже, связана с encfs.

У меня есть резервные копии всех данных, и я могу просто удалить их все и переписать, но не поврежденная копия находится в системе с очень низкой скоростью загрузки (она у меня дома), и для ее синхронизации потребовалось 2 дня; Я неохотно перезагружаюсь (не потому, что у меня нет 2 дней, а потому, что я не хочу, чтобы мой домашний интернет в основном зависал в течение 2 дней).

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

Если мне нужно перезапустить, может кто-нибудь сказать мне хороший способ проверить, какие файлы в каталоге имеют ошибки ввода-вывода ?? Редактировать: в конце концов, я использовал ужасный способ - запустите file для каждого файла, используя find , а затем взломав мой путь к списку плохих файлов, используя grep и emacs, используя метод, который не будет работать, если какие-либо файлы называются вещами как "ошибка вывода" :-)

РЕДАКТИРОВАТЬ (один год спустя): я жил с этим вопросом уже более года. Я использовал обходной путь Мальте. Однако на прошлой неделе я впервые потерял данные. Я сделал существенные изменения в каталоге encfs, я не сделал ничего странного, кроме перемещения данных, а затем мой ночной сценарий (который, я мог бы добавить, занимает больше часа, чтобы работать с большим количеством чтения дисков, каждую ночь на обоих Машины с Ubuntu, на которых у меня запущены Dropbox и Encfs), сказали мне, что определенные файлы дают ошибки ввода-вывода на обоих концах. Мне пришлось восстанавливать файлы, используя функцию Dropbox для восстановления удаленных файлов, что было очень трудно, потому что, конечно, все имена файлов зашифрованы, поэтому мне пришлось использовать encfsctl и т.д.

Это подтолкнуло меня к действию. Поэтому я прикусила пулю и настроила второй каталог Encfs, на этот раз с другими глобальными настройками (я не знаю, как изменить эти настройки в данном каталоге Encfs, и я почти уверен, что это невозможно, поэтому единственный способ сделать это насколько я мог видеть, я должен был скопировать сейчас 300 гигабайт из одного каталога в другой, я должен был сделать это сейчас, потому что, когда я получу до 500 гигабайт, я не смогу хранить две копии в своем Dropbox, который имеет ограничение в 1000 гигов).

Так что я сделал? Я создал другую зашифрованную систему хранения файлов без использования файла инициализации вектора цепочки, ни за файл инициализации векторов и нет внешней IV цепочки. Да, я знаю, что это менее безопасно! Да, я знаю, что это не работает для всех! Да, я даже знаю, что аудит безопасности на Encfs пришел к выводу, что я не должен хранить 100 000 идентификаторов пользователей, паролей и данных кредитной карты, используя Encfs! Но это не то, для чего я использую Encfs. Все, что я хочу сделать, - это использовать Dropbox, но для того, чтобы убедиться, что если Dropbox взломан или если недовольный сотрудник Dropbox пропустит данные, тогда мои данные - это не то, что продается. У меня здесь нет секретов качества боеприпасов, у меня просто есть фотографии моей семьи и связанные с работой вещи, такие как ссылки, которые я не хочу, чтобы их случайно просочились.

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

https://stackoverflow.com/questions/24966676/transport-endpoint-is-not-connected

https://github.com/vdudouyt/mhddfs-nosegfault

https://github.com/vgough/encfs/issues/109

А также предложение использовать fsck в каталоге encfs.

Мне не хватает эксперта, чтобы знать, имеет ли какое-либо из них значение. Что я знаю, так это то, что со вчерашнего дня я "начал заново" с Encfs, и через пару месяцев я сообщу о том, исправила ли это проблему для меня.

ОБНОВЛЕНИЕ Спустя два года я могу с уверенностью заявить, что изменение этих настроек файла Encfs устранило проблему за счет возможного ослабления моей безопасности. У меня не было ошибок ввода-вывода с тех пор, как я внес эти изменения в настройку.

3 ответа3

6

У меня точно такая же проблема, она также началась пару недель назад. Просто чтобы сделать это более полным:

  • Перемещение файлов снова и снова устраняет симптомы
  • Все мои машины Ubuntu, так что это не может быть связано с Windows
  • У меня есть три машины в группе синхронизации, и проблема возникает как минимум на двух из них. Ниже приведен расширенный сценарий, чтобы каждая машина могла a) перечислить свои ошибки и b) попытаться исправить ошибки других.

Найти поврежденные файлы:

saveFile="$(hostname)-corruptFiles"
find $dir -exec file {} \;|grep "output error" > /tmp/corruptFilesRaw.txt
cat /tmp/corruptFilesRaw.txt | awk -F  ":" '{print $1}' > $saveFile

Исправить поврежденные файлы:

while read i <&3; do
    #check if file is corrupted on this machine as well
    file "$i" >/dev/null 2>&1
    retcode=$?
    if [ $retcode -eq 0 ]; then
        #if not, fix it
        mv "$i" /tmp/crap
        sleep 5
        mv /tmp/crap "$i"
        sleep 1
    else
        #if it is corrupt here as well, skip it
        echo $i >> /tmp/remainingCorruptedFiles
    fi;
done 3<$fileList

#replace file list with list of remaining corrupt files
rm $fileList
mv /tmp/remainingCorruptedFiles $fileList

У меня есть эти два сценария в корне расшифрованной папки, поэтому и сценарий, и списки поврежденных файлов синхронизируются между всеми компьютерами

3

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

Я бы использовал "потоковое" кодирование имени файла и только "векторы инициализации для каждого файла" и «дыры в файле, передаваемые в зашифрованный текст», чтобы сделать Encfs надежным.

И не слушайте парня, который говорит, что encfs уязвим для атак водяных знаков. О, конечно, это связано с природой. Только не помещайте туда с узнаваемыми образцами как разорванные компакт-диски.

Это будет правильной настройкой Encfs. Включена только уникальная поддержка iv для каждого файла в конце файла.

Version 6 configuration; created by EncFS 1.7.4 (revision 20100713)
Filesystem cipher: "ssl/aes", version 3:0:0 (using 3:0:2)
Filename encoding: "nameio/stream", version 2:1:0 (using 2:1:2)
Key Size: 256 bits
Using PBKDF2, with 206833 iterations
Salt Size: 160 bits
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
File holes passed through to ciphertext.
2

Итак, я хотел разобраться с этим сегодня, вот что я сделал. YMMV.

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

Хорошо, так что сначала я сделал резервную копию всего на компьютере X.

Во вторых я побежал (в каталог где все проблемы были по Y)

$ find . -exec file '{}' \; | grep "output error" > ~/io_problems.txt

[в некоторых моих именах файлов были пробелы, но ни в одном не было символов новой строки или чего-то еще подобного]

Я запустил wc на io_problems.txt и обнаружил, что в моем файле было более 2000 строк и, следовательно, более 2000 ошибок ввода-вывода в моей системе. Уч.

Затем я использовал короткий макрос emacs для редактирования io_problems.txt: в каждой строке я нашел строку : ERROR: cannot read и просто удалил всю оставшуюся строку, начиная с двоеточия. Я сделал это, набрав (в emacs) (C-x ( C-s : ERROR: cannot read [now press left arrow key to get back to the first colon] C-k [right arrow key] C-x ) C-u 2500 C-x e в emacs. Я уверен, что мог бы использовать sed, awk или что-то еще, я просто больше привык к emacs. Я переименовал полученный файл list.txt .

До сих пор у меня остался файл list.txt который содержит список имен файлов (которые могут содержать пробелы), которые являются проблематичными для Y.

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

while read i <&3; do
  mv "$i" ~/crap
  sleep 5
  mv ~/crap "$i"
  sleep 5
  done 3<~/list.txt

Спящий режим таков, что я не перегружаю Dropbox, что как-то вызвало первоначальные проблемы (хотя я не верю, что проблема с Dropbox; я провел обширное тестирование с зашифрованными файлами и не смог найти каких-либо различий в файлы в X и Y, мое незнание с помощью encfs/fuse не позволило мне провести более тщательное тестирование, чтобы выяснить, в чем проблема).

2000 файлов и 10 секунд на файл означает, что вся операция займет более 5 часов. Это работает для меня.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .