使用 Dropbox 文件夹内的 encfs 文件夹的“输入/输出错误”

Question

我的 Dropbox 中有一个 200 gig Encfs 加密文件系统，可被多台机器访问，直到现在我才遇到任何问题。

我在一台（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 使用一种方法，如果任何文件被称为“输出错误”:-)

编辑（一年后）：我已经忍受这个问题一年多了。我一直在使用malte 的解决方法。然而上周，有史以来第一次，我真的丢失了数据。我在 encfs 目录中进行了大量更改，除了移动数据之外，我没有做任何奇怪的事情，然后是我的夜间脚本（我可能会补充说，每天晚上在两个运行 Dropbox 和 Encfs 的 ubuntu 机器）告诉我，某些文件在两端都出现了 I/O 错误。我不得不使用 Dropbox 的“恢复已删除的文件”功能恢复文件，这很痛苦，因为当然所有文件名都是加密的，所以我不得不使用encfsctl等。

这促使我采取行动。所以我硬着头皮设置了第二个 Encfs 目录，这次使用不同的全局设置（我不知道如何在给定的 encfs 目录中更改这些设置，而且我很确定这是不可能的，所以我只能这样做，据我所知，是将现在 300 个演出从一个目录复制到另一个目录；我现在必须这样做，因为当我达到 500 个演出时，我将无法在我的保管箱中存储两个副本1000 场演出的限制）。

那我做了什么？我设置另一个加密文件存储系统中使用没有文件名初始化向量链接，没有每个文件初始化矢量和无外部IV链接。是的，我知道这不太安全！是的，我知道这并不适合所有人！是的，我什至知道对 Encfs 的安全审计得出的结论是，我不应该使用 Encfs 存储 100,000 个用户 ID、密码和信用卡详细信息！但这不是我使用 encfs 的目的. 我想要做的就是使用 Dropbox，但要确保如果 Dropbox 被黑客入侵，或者有心怀不满的 Dropbox 员工泄露了数据，那么我的数据不是被出售的东西。我这里没有军需品级的秘密，我只有家人的照片和工作相关的东西，比如我不想被随意泄露的参考资料。

当我在这里时，让我提一下我在去年发现的一些其他链接，这些链接可能与此问题相关，也可能不相关。我对 FUSE 的工作原理了解不够。但鉴于这是我的问题，而且这对我来说已经是一个主要问题 1 年了，我想我会使用这个问题作为我对他和可能相关问题的发现的个人收藏。

/sf/ask/1747667351/

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

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

还有fsck在 encfs 目录上使用的建议。

我不够专业，无法知道这些是否相关。我所知道的是，截至昨天，我已经“重新开始”使用 Encfs，我将在几个月后报告这是否为我解决了问题。

更新两年后，我现在可以自信地说，更改这些 Encfs 文件设置已经解决了问题，但代价是可能会削弱我的安全性。自从我在设置中进行这些更改后，我就没有出现过 I/O 错误。

Answer 1

我有完全相同的问题，它也是几周前才开始的。只是为了使这更完整：

• 再次移出和移入文件确实可以解决问题
• 我所有的机器都是 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

我在解密文件夹的根目录中有这两个脚本，因此脚本和损坏文件列表在所有机器之间同步

Answer 2

如果您在“最大安全”模式下运行 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.