"Ошибки ввода / вывода" с использованием папки encfs внутри папки Dropbox
У меня есть зашифрованная файловая система 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 ответа
Если вы запускаете 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.
У меня точно такая же проблема, она также началась пару недель назад. Просто чтобы сделать это более полным:
- Перемещение файлов снова и снова устраняет симптомы
- Все мои машины 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
У меня есть эти два сценария в корне расшифрованной папки, поэтому и сценарий, и списки поврежденных файлов синхронизируются между всеми компьютерами
Хорошо, так что я хотел разобраться с этим сегодня, вот что я сделал. 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 часов. Это работает для меня.
В настоящее время я ожидаю завершения этого цикла, но предварительные тесты, похоже, указывают на то, что проблема решается медленно, но верно.