Omitir permisos predeterminados al montar volúmenes HFS + en Linux


8

Tengo un MacBook Pro de arranque dual con Snow Leopard y Kubuntu 11.10, y quiero leer (no me importa escribir) el directorio de inicio de mi Mac cuando estoy ejecutando Kubuntu.

Puedo montarlo sin ningún problema, pero mi usuario en Kubuntu no puede ver los archivos en el HFS + propiedad del usuario mac, debido a diferentes uid (502 en Mac, 1000 en Kubuntu).

Mirando los documentos del kernel sobre HFS + , leí que:

When mounting an HFSPlus filesystem, the following options are accepted:
[CUT]
    uid=n, gid=n
        Specifies the user/group that owns all files on the filesystem
        that have uninitialized permissions structures.
        Default:  user/group id of the mounting process.

Así que intenté usar estas opciones:

$ sudo mount -t hfsplus -o uid=1000,gid=1000 /dev/sda2 /mnt/Mac

Pero parecen no hacer nada: sigo viendo los mismos permisos cuando miro alrededor usando ls -l. Puede que me falte algo, ¿alguna pista?

Sé que puedo cambiar mi identificación de usuario en Ubuntu para que coincida con Mac Os X, pero preferiría evitarlo si es posible.

Respuestas:


9

bindfses la respuesta. Tomará un sistema de archivos ya montado y le proporcionará una vista con el uid que desee:

sudo apt-get install bindfs
mkdir ~/myUIDdiskFoo
sudo bindfs -u $(id -u) -g $(id -g) /media/diskFoo ~/myUIDdiskFoo

Editar:

Además, al leer el documento, me di cuenta de que la mapopción (1.10 y posterior) podría encajar mejor:

sudo bindfs --map=502/1000 /media/diskFoo ~/myUIDdiskFoo

Muy buena solución. Resuelve el problema sin cambiar los comportamientos predeterminados de los sistemas operativos, y hace posible muchas más opciones. Solo tenga cuidado si el sistema se comparte con otros usuarios, esto puede exponer archivos privados a una audiencia inesperada.
gerlos

1
Si. Me sorprendió que la utilidad de montaje del sistema no ofrezca esta capacidad. Alternativamente, puede usar la mapfuncionalidad de bindfs para simplemente mapear al usuario 502 a 1000, lo que podría ser más seguro y más de lo que pretendía.
Catskul

Como no tengo la reputación de comentar, solo voy a notar que hay un pequeño error en la respuesta de Catskul, y = falta, debería ser: sudo bindfs --map = 502/1000 / media / diskFoo ~ / myUIDdiskFoo
J. Simon van der Walt

1

Al final, creé un usuario de Linux con el mismo UID de mi usuario de mac os x, pero no puede examinar todos los directorios de mi casa en mac hfs + volume porque muchos archivos pertenecían al usuario de Mac "desconocido", UID 99 (ver http://googlemac.blogspot.com/2007/03/user-99-unknown.html ).

Parece que lo hicieron para permitirle montar y leer su volumen cuando lo conecta a una computadora diferente. Cuando un usuario normal mira esos archivos propiedad de UID 99, los ve como su propietario. Bastante extraño. Solo la raíz los ve como son.

Entonces reinicié en Mac Os X, inicié sesión con un usuario diferente con privilegios administrativos y usé chown -R 502: 20 / Users / gerlos / * para cambiar el propietario de cada archivo en mi casa. Ahora puedo leer todo sin ningún problema.

Observaciones:

  • La herramienta predeterminada de la interfaz gráfica de usuario de Kubuntu para crear nuevos usuarios en Kubuntu 11.10 no puede crear usuarios con UID inferior a 1000. En su lugar, use adduser en el terminal.
  • puede conocer su UID de usuario utilizando el comando "id" en el terminal.
  • En Mac OS X, debe ser root para ver el verdadero propietario de los archivos. Así que espere resultados diferentes si escribe "ls -n / Users / gerlos" y "sudo ls -n / Users / gerlos".

Esa diferencia en OSX entre el usuario "real" de Unix y el usuario reconocido por Finder me dio mucho dolor de cabeza ... incluso puede hacer que algunas aplicaciones en OSX se comporten de manera extraña (por ejemplo, Dropbox no sincronizará sus archivos). Para evitar cualquier problema, inicie sesión en su sistema OSX, abra una terminal y asegúrese de que su usuario de Unix sea dueño de todo lo que su usuario de OS X ya posee. Quizás no entiendo algo, pero en mi experiencia usar la GUI no es suficiente.
gerlos

1

En realidad, estoy buscando hacer algo similar cuando me encuentro con esta pregunta. Tengo entendido, mirando desde su primera publicación, que la opción de montaje solicitada es preguntar qué usuario uid debería usarse en lugar del valor predeterminado de su sistema Linux (es decir, uid 1000). Por lo tanto, debería usar 502, que es el propietario esperado del sistema de archivos que está tratando de montar.

He probado esto en mi propia situación, y funcionó muy bien, con uid 99 para un sistema de archivos compartido entre mis sistemas. Con esto no tendré que andar cambiando de uids. Así que gracias por compartir. Puede que esto ya no sea de gran utilidad para usted, pero puede ayudar a otra persona. Salud


1
Derecha. La mejor solución es dejar en paz los UID y los permisos, montar su sistema de archivos HFS + como lo hace normalmente y luego montar su hogar bajo el sistema de archivos HFS + utilizando bindfs, para que todo parezca ser propiedad de su usuario de Linux. De esta manera, nunca necesitará usar UID personalizados, ni cambiar los permisos en el sistema de archivos HFS +, por lo que conserva el comportamiento predeterminado en ambos sistemas. Como puede volver a montar con bindfs la casa de cada usuario, puede preservar archivos privados incluso en sistemas compartidos, manteniéndolos accesibles para los usuarios.
gerlos
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.