web-dev-qa-db-ja.com

Dropboxフォルダー内のencfsフォルダーを使用した「入出力エラー」

Dropboxに200ギガのEncfs暗号化ファイルシステムがあり、複数のマシンからアクセスされていますが、これまで問題はありませんでした。

1台の（ubuntu）コンピューターXで約10ギガのデータを移動し、2日後に別の（ubuntu）コンピューターYで同期が終了したときに、いくつかの問題が発生しました。一部のファイルがYで読み取れず、入力が表示されます。 /出力エラー、例：.

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

したがって、どういうわけかファイルシステムが破損しています。すべてのファイルはコンピューターXで正常に読み取ることができます。このプロパティで約20個のファイルに遭遇しました。もっとあるかもしれません。通常、ディレクトリでは、このエラーで失敗するファイルはごくわずかであり、さらに多くのファイルで問題ありません。

また、システムをWindowsマシンZで実行しています。 Zのファイルを調べたところ、IOエラーが発生しました（ただし、Windowsのエラーメッセージはかなりわかりにくいものでした）。したがって、ある意味で、問題はほぼ確実に「Xの終わり」にあります。

入出力エラーが発生しているディレクトリに対応する、実際の暗号化されたDropboxディレクトリ内のディレクトリに移動することができました。すべての（暗号化された）ファイルは正常に読み取ることができるため、問題は物理ディスクの実際のIOエラーではなく、encfsにあるようです。

すべてのデータをバックアップしていて、すべてを削除して書き直すことができますが、破損していないコピーは、アップロード速度が非常に遅いシステム上にあり（自宅にあります）、同期に2日かかりました。再起動するのは気が進まない（2日がないからではなく、基本的に自宅のインターネットを2日間遅くしたくないから）。

グーグルは私を何にも導きませんでした。私が言っているように、私が現在避けたいと思っている「再起動して再試行する」ことを除いて、私は次に何をすべきかを知ることに途方に暮れています。ファイルシステムをディレクトリに保存する方法がよくわからないため、問題のデバッグを開始する方法がわかりません。

再起動する必要がある場合、誰かがディレクトリ内のどのファイルにIOエラー?? 編集：）があるかを確認するための良い方法を教えてもらえますか？方法-fileを使用して各ファイルでfindを実行し、ファイルが呼び出された場合に機能しないメソッドを使用してgrepとemacsを使用して不良ファイルのリストにハッキングします「出力エラー」のようなもの:-)

編集（1年後）：私はこの問題を1年以上抱えています。私は malteの回避策 を使用しています。しかし先週、初めて実際にデータを失いました。私はencfsディレクトリに大幅な変更を加え、データを移動する以外に奇妙なことは何もしませんでした。その後、毎晩スクリプトを実行しました（追加するかもしれませんが、毎晩、両方で大量のディスク読み取りを実行するには1時間以上かかります）。 DropboxとEncfsを実行しているubuntuマシン）は、特定のファイルが両端でI/Oエラーを引き起こしていると教えてくれました。 Dropboxの「削除されたファイルの復元」機能を使用してファイルを復元する必要がありました。もちろんすべてのファイル名が暗号化されているため、encfsctlなどを使用する必要がありました。

これは私に行動を起こさせました。だから私は弾丸を噛み、今度は異なるグローバル設定で2番目のEncfsディレクトリを設定します（特定のencfsディレクトリでこれらの設定を変更する方法がわからず、それが不可能であると確信しているので、これを行う唯一の方法、私が見る限り、現在300ギガをあるディレクトリから別のディレクトリにコピーすることでした。最大500ギグになると、ドロップボックスに2つのコピーを保存できなくなるため、今これを行う必要がありました。 1000ギガの制限）。

それで私は何をしましたか？ noファイル名初期化ベクトルチェーン、noファイルごとの初期化ベクトル、no外部IVチェーンを使用して、別の暗号化ファイルストレージシステムをセットアップしました。はい、これは安全性が低いことを私は知っています！はい、これがすべての人に役立つわけではないことを私は知っています！はい、Encfsのセキュリティ監査で、Encfsを使用して100,000のユーザーID、パスワード、クレジットカードの詳細を保存するべきではないという結論に達したことがわかっています。しかしこれは私が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

また、encfsディレクトリでfsckを使用することをお勧めします。

私はこれらのいずれかが関連しているかどうかを知るのに十分な専門家ではありません。私が知っていることは、昨日の時点でEncfsを「再開」したことです。これで問題が解決したかどうかについて、数か月後に報告します。

[〜＃〜] update [〜＃〜]2年後、これらのEncfsファイル設定を変更することで問題が修正されたと自信を持って述べることができます。おそらく私のセキュリティを弱めるコスト。セットアップでこれらの変更を行って以来、I/Oエラーは発生していません。

ubuntuencryptionsyncdropboxencfs
5
eric

「最大セキュリティ」モードでencfsを実行している場合、または「ファイル名からIVヘッダーへのチェーン」を有効にしている場合は、Dropboxのようなサービスで機能しなくなります。有効にしないでください。実際には、決して使用しないでください。ファイルデータ暗号化IVのファイルパスに依存するのはまったく愚かです。

Encfsの信頼性を高めるために、「ストリーム」ファイル名エンコーディングと「ファイルごとの初期化ベクトル」および「暗号文に渡されるファイルホール」機能のみを使用します。

そして、encfsが透かし攻撃に対して脆弱であると言う男に耳を傾けないでください。もちろん、それはその性質のためです。破れたCDのような認識可能なパターンでそこに置かないでください。

これは正しい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.
3
Dilyin

私はまったく同じ問題を抱えています、それも数週間前に始まったばかりです。これをより完全にするためだけに：

  • ファイルを出し入れすることで症状は修正されます
  • 私のマシンはすべてUbuntuなので、Windowsに関連することはできません
  • 同期グループに3台のマシンがあり、少なくとも2台で問題が発生します。各マシンが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

復号化されたフォルダのルートにこれらの2つのスクリプトがあるため、スクリプトと破損したファイルのリストの両方がすべてのマシン間で同期されます

6
malte

さて、今日はこれを整理したかったので、これが私がしたことです。 YMMV。

注：問題の原因はわかりませんでした。しかし、テストの結果、I/OエラーのあるファイルがコンピューターYで見つかった場合は、コンピューターXでファイルを取得し、ファイルシステムから移動して、再度戻すと問題が解決することがわかりました。おそらく再び私を噛むかもしれない根本的な問題があるので、私はこの解決策が本当に好きではありませんが、根本的な問題を診断する方法がわかりません。

OK、最初にコンピュータXのすべてをバックアップしました。

次に、実行しました（すべての問題がYにあったディレクトリで）

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

[私のファイル名のいくつかにはスペースがありましたが、改行などはありませんでした]

Io_problems.txtでwcを実行したところ、そのファイルに2000行を少し超えているため、システムに2000を超えるI/Oエラーが発生していることがわかりました。痛い。

次に、短いemacsマクロを使用してio_problems.txtを編集しました。各行で文字列: ERROR: cannot readを見つけ、コロンから始まる残りの行をすべて削除しました。私はこれをemacsで（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と入力して行いました。 sedやawkなどを使用できたはずですが、emacsに慣れています。結果のファイルの名前をlist.txtに変更しました。

これまでのところ、Yで問題となるファイル名（スペースが含まれている可能性があります）のリストを含むファイルlist.txtが残っています。

ここで大きな瞬間です。このファイルのリストをループし、ファイルごとにファイルシステムから移動して、再び元に戻す必要があります。ファイル名にはスペースが含まれる場合があります。したがって、ループにはファイル記述子を使用します。

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

スリープは、ドロップボックスを圧倒しないようにするためです。これが、元の問題の原因であると考えられます（ただし、問題がドロップボックスにあるとは思われません。暗号化されたファイルで広範なテストを行ったところ、違いは見つかりませんでした。 XとYのファイル。encfs/ Fuseを知らなかったため、実際に問題を見つけるためにこれ以上厳密なテストを行うことができませんでした）。

2000ファイルとファイルあたり10秒は、操作全体に5時間以上かかることを意味します。これは私にとってはうまくいきます。

現在、このループが終了するのを待っていますが、予備テストでは、問題がゆっくりと、しかし確実に解決されていることが示されているようです。

2
eric