encfsボリュームで破損していると誤って見なされるファイル

OS X Mavericks 10.9.2を実行しているMacBook Pro Retina Late 2013でMacPorts 2.2.1 を使用encfs @1.7.5してosxfuse @2.6.4インストールしています。encfsボリューム内の特定のファイル（xlsx、pdfなど）を開くと、「Xが破損しているため開くことができません」というエラーが表示されます。ゴミ箱に移動することをお勧めします。ただし、そのファイルを別の場所（encfsボリューム上ではない場所）にコピーすると、問題なく動作するようです。どうしてこれなの？

編集：私はオンラインで調べて、GateKeeperを無効にすることに関する投稿を見つけました。それはトリックをしました。本質的には、「セキュリティ設定->セキュリティとプライバシー->どこからでもダウンロードされたアプリケーションを許可する」に入ります。

ソリューションが機能することを理解していますが、なぜ機能するのか知りたいのですが。前もって感謝します。

編集2：また、誰かが私の投稿にのタグを付けることができればencfs、それは非常に高く評価されます。

私はここで答えを見つけました（BoxCryptorの場合）：

特別な状況下では、Mac OS Xは拡張属性「com.apple.quarantine」を、例えばインターネットからダウンロードされたファイルに追加します。これは、BoxCryptorフォルダ内のファイルにも発生する可能性があります。暗号化されたファイルにこの拡張属性が設定されている場合、BoxCryptorボリュームでプレーンテキストファイルを開こうとすると、「破損しています」というエラーメッセージが表示されます。

より安全な次の回避策も試してください：

x）ターミナルを開く（アプリケーション->ユーティリティ）

y）次のコマンドを実行します（パスを置き換えます）。

$ xattr -r -d com.apple.quarantine / path / to / encfs / mount / point

@apmouseは正しいです。xattrでファイルを修復できます。ただし、これを繰り返し行う必要があります。ファイルを保存するたびに、隔離フラグが追加されます。

ご指摘のとおり、安全性は低くなりますが、より便利な方法があります。GateKeeperを無効にします。

ソリューションが機能することを理解していますが、なぜ機能するのか知りたいのですが。前もって感謝します。

最初に注意すべきことは、Keynoteに移動してFile→Openを選択すると、「破損した」ファイルを問題なく開くことができるということです。これは、ファイルを開かないようにするために介入しているのは実際にはFinderであることを意味します。

「_____が破損しており、開けない」というエラーメッセージは、実際には署名エラーです（ここを参照–約3/4のところ）。これは、GateKeeperが有効な署名を検証できないことを意味します。署名の検証は実行可能ファイルに適用されることになっていますが、まだこの状況でバグが発生している理由がわかりません。

私はosxfuseのサンプルループバックファイルシステムをコンパイルして、そこに同じ「損傷した」ファイルを置いてみましたが、うまく開きました。したがって、このバグはencfsに固有のものであり、一般的にosxfuseに固有のものではないと思います。

それだけの価値があるので、この正確な問題については、osxfuseプロジェクトにチケットが公開されています。この問題が発生している場合は、そのチケットに詳細を投稿してください。

お役に立てれば...

なぜ Appleが「このボリュームは安全である」と言う簡単な方法がないように見えるのかはわかりませんが、問題はencfsにとってかなり簡単に解決できます。encfsボリュームのマウントに使用するスクリプトを以下に示します。属性の問題を自動的に解決し、ボリュームを閉じることを覚えておくのにも役立ちます。encfs dirとマウントポイントを読み取ることで拡張できます。コマンドラインからですが、タイプミスがセキュリティリスクを引き起こす可能性があるため、私はそれを好みません。それは、ボックスクリプターのような他のマウントメカニズムに比較的簡単に適合させるべきです。それは私にとってはうまくいきますが、あなたはそれをあなた自身のために使うべきかどうかを決める際にあなた自身の専門知識に依存しています。具体的には、私はセキュリティの専門家ではなく、セキュリティホールが開いているかどうかを判断する資格がありません（特に実行中、特に共有マシンで）。

#!/bin/bash
# script to mount encrypted volume

ENCFSDIR=<encfs dir>
MOUNTPOINT=<mount point>
SAFELOC=<somewhere outside mounted volume>

encfs $ENCFSDIR $MOUNTPOINT

cd $MOUNTPOINT
xattr -r -d com.apple.quarantine .
MY_PROMPT='SECRET: '
echo 'noscecrets to finish'
while :
do
  echo -n "$MY_PROMPT"
  read line
  if [ 'nosecrets' == "$line" ] ; then
    break
  fi
  eval "$line"
done

\# and clean up
cd $SAFELOC
umount $MOUNTPOINT

exit 0

毎回実行する必要のあるコマンドではなく、これに対してより永続的な回避策があると思います。先にバグレポートで述べたように：

私は、OS Xはすべての種類のジョブにシステムユーザーとシステムデーモンを使用していると思いました。おそらくカーネルは、これらのファイルに対して別のユーザーまたはrootとしていくつかの作業を実行できることを期待しており、破損した場合はそれらを損傷としてマークします動作しません。

そのため、sshfsバイナリをとマークし、コマンドラインにマウントオプションsetuidを追加しました。-o allow_otherマウントsshfsされたボリュームでドキュメントを確実に開いて編集できるようです。それが機能しなくなった場合、私は実験と追跡を続けます。

もちろん、私はsetuidルートバイナリが存在することについて心配していますが、NFSまたはSMBを取得するためにファイルサーバー側でroot権限を必要とするデーモンを実行するオプションよりも優れているようです。:)

これallow_otherはFUSEマウントオプションであり、に固有ではないのでsshfs、この回避策はencfs同様に機能すると思います。誰かがそれを試してみてうまくいったかどうかを知るのは素晴らしいことです！

@Glyphに感謝します。私が知ることができることから、あなたの手順を実行した後にそれが機能しているようです。私はこれらのステップに従いました：

1. 最初に、osxfuse管理グループに属しているグループを追加する必要がありました。そうしないと、allow_otherがサポートされていない操作で失敗します。

   sysctl -w osxfuse.tunables.admin_group=12
   

2. 次に、-o allow_otherを使用してencfs

私はそれを少しだけ試しましたが、私が持っていた再現可能な失敗のケースは今や機能しているようです。