Archivos mal considerados como dañados en el volumen de encfs

Estoy utilizando encfs @1.7.5 osxfuse @2.6.4 y osxfuse @2.6.4 instalado a través de MacPorts 2.2.1 en mi MacBook Pro Retina finales de 2013 que está ejecutando OS X Mavericks 10.9.2. Al abrir ciertos files (por ejemplo, xlsx, pdf) en mi volumen de encfs , obtengo un error "X está dañado y no se puede abrir". así como una sugerencia para moverlo a la basura. Sin embargo, cuando copio ese file en otro lugar (es decir, no en el volumen de encfs ), parece que funciona bien. ¿Por qué es esto?

EDIT: Busqué en línea y encontré un post que implica desactivar GateKeeper. Hizo el truco. En esencia, entra en "Preferences de security -> Seguridad y privacidad -> Permitir aplicaciones descargadas desde: Anywhere".

  • Activity Monitor repentinamente mostrando todos los núcleos en el icono de Dock
  • ¿Cómo instalar Xcode 6?
  • ¿Cómo puedo convertir una fuente de maleta?
  • Restauración de la configuration de la window para configuraciones de monitor
  • ¿Cómo puedo eliminar la sombra de la window en El Capitán?
  • Cómo eliminar completamente Garage Band de macOS?
  • Entiendo que la solución funciona, pero me gustaría saber por qué funciona. Gracias por adelantado.

    EDIT 2: Además, si alguien podría labelr mi publicación con encfs , sería muy apreciado.

  • ¿Cómo puedo search un tipo específico de file en Mac?
  • ¿Qué otras aplicaciones tienen menus de debugging secretos?
  • ¿Cómo puedo borrar todas las notifications de OS X con un solo clic?
  • Lista de todos los dispositivos conectados, lsblk para Mac OS X
  • ¿Alternativa de PackageMaker?
  • Cómo configurar PATH para las aplicaciones iniciadas por Finder
  • 5 Solutions collect form web for “Archivos mal considerados como dañados en el volumen de encfs”

    He encontrado la respuesta aquí (para BoxCryptor):

    Bajo circunstancias especiales, Mac OS X agrega el atributo extendido 'com.apple.quarantine' a un file que se descargó, por ejemplo, de Internet. Esto también puede suceder a los files dentro de la carpeta de BoxCryptor. Si un file encryption tiene este set de attributes extendido, recibirá el post de error "está dañado" al intentar abrir el file de text plano en el volumen de BoxCryptor.

    También intente esto, una solución más segura:

    x) Abrir Terminal (Aplicaciones -> Utilidades)

    y) Ejecute el siguiente command (sustituya la ruta):

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

    @apmouse es correcto: puede reparar el file con xattr. Pero usted tiene que hacer eso repetidamente – cada vez que usted ahorra un file él tendrá la bandera de la cuarentena agregada de nuevo a él.

    Como usted señaló, hay una alternativa less segura pero más conveniente: desactivar GateKeeper.

    cómo deshabilitar gatekeeper

    Entiendo que la solución funciona, pero me gustaría saber por qué funciona. Gracias por adelantado.

    Lo primero a tener en count es que si entra en Keynote y elige Archivo → Abrir, puede abrir el file "dañado" sin problemas. Esto implica que es en realidad Finder que está interviniendo para evitar la apertura del file.

    El post de error "_____ está dañado y no se puede abrir" es en realidad un error de firma (vea aquí – aproximadamente 3 / 4ths de la manera hacia abajo), lo que significa que GateKeeper no puede verificar una firma válida. Se supone que la verificación de la firma se aplica a los ejecutables, y todavía no he descubierto por qué se está escuchando en esta situación.

    Intenté comstackr el sistema de file de la muestra de loopback del osxfuse y poner el mismo file "dañado" allí y se abre muy bien. Así que creo que este error es específico de encfs – no a osxfuse en general.

    Para lo que vale, hay un ticket abierto en el proyecto osxfuse para este problema exacto. Si tienes este problema, publica tus datos en ese ticket.

    Espero que esto ayude…

    No sé por qué Apple no parece tener una manera sencilla de decir "este volumen es seguro", pero el problema es bastante fácil de resolver para encfs. A continuación, encontrará un script que utilizo para montar volúmenes de encfs; automáticamente resuelve el problema de atributo, y también ayuda a recordar cerrar volúmenes. Podría extenderse leyendo el directory de encfs y el punto de assembly desde la command-line, pero prefiero no hacerlo porque los errores tipocharts podrían crear riesgos de security. Debe ser relativamente fácil de adaptar a otros mecanismos de assembly, tales como boxcryptor. Funciona para mí, pero confías en tu propia experiencia para decidir si usarlo por ti mismo. Muy específicamente, no soy un experto en security, y no estoy calificado para juzgar si abre algún agujero de security (especialmente mientras se está ejecutando, y especialmente en máquinas compartidas).

     #!/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 #! / bin / bash #!/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 

    Creo que tengo una solución más persistente para esto en lugar de un command que necesita ejecutar cada vez. Como acabo de mencionar en el reporte de bug upstream :

    Pensé para mí mismo, OS X utiliza los usuarios del sistema y los demonios del sistema para todo tipo de trabajos, tal vez el núcleo está esperando poder hacer algún trabajo como otro usuario, o como root, a estos files, y marcándolos como dañados cuando no funciona.

    Así que sshfs mi binary sshfs como setuid , y agregué la opción -o allow_other mount a mi command-line sshfs , y … Parece ser capaz de abrir y editar documentos de forma confiable en el volumen montado. Continuaré experimentando y siguiendo si deja de funcionar.

    Por supuesto estoy preocupado por un binary de raíz setuid mentir alnetworkingedor, pero parece mejor que la opción de ejecutar un daemon que requiere privilegios de root en el lado del server de files de las cosas para get NFS o SMB. 🙂

    Teniendo en count que allow_other es una opción de assembly FUSE y no es específico para sshfs , creo que esta solución también funcionaría para encfs . Sería genial saber si alguien lo intentó y funcionó!

    Gracias @Glyph, de lo que puedo decir que parece estar funcionando después de seguir sus pasos. He seguido estos pasos:

    1. Primero tuve que agregar un grupo al que pertenezco al grupo de administración de osxfuse, de lo contrario el allow_other fallaría con la operación no soportada.

       sysctl -w osxfuse.tunables.admin_group=12 
    2. Luego usamos el -o allow_other para encfs

    Sólo lo he probado un poco, pero el caso de fallo reproducible que tenía parece estar funcionando.

    Loving Apple Products like poisoning (iPhone, iPad, iMac, Macbook, iWatch).