Umgehen von Standardberechtigungen beim Mounten von HFS + -Volumes unter Linux


8

Ich habe ein Dual-Boot-MacBook Pro mit Snow Leopard und Kubuntu 11.10 und möchte mein Home-Mac-Home-Verzeichnis lesen (egal, ob ich es schreibe), wenn ich Kubuntu verwende.

Ich kann es ohne Probleme bereitstellen, aber mein Benutzer auf Kubuntu on kann die Dateien auf dem HFS +, die dem Mac-Benutzer gehören, aufgrund unterschiedlicher UIDs nicht sehen (502 auf Mac, 1000 auf Kubuntu).

Beim Betrachten von Kerneldokumenten zu HFS + habe ich Folgendes gelesen:

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.

Also habe ich versucht, diese Optionen zu verwenden:

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

Aber sie scheinen nichts zu tun: Ich sehe immer noch die gleichen Berechtigungen, wenn ich mich mit ls -l umsehe. Mir fehlt vielleicht etwas, ein Hinweis?

Ich weiß, dass ich meine Benutzer-ID unter Ubuntu ändern kann, um sie mit Mac Os X abzugleichen, aber ich würde es vorziehen, wenn möglich zu vermeiden.

Antworten:


9

bindfsist die Antwort. Es wird ein bereits gemountetes Dateisystem verwendet und eine Ansicht davon mit der gewünschten UID bereitgestellt:

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

Bearbeiten:

Beim Lesen des Dokuments wurde mir auch klar, dass die mapOption (1.10 und höher) möglicherweise besser passt:

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

Sehr coole Lösung. Es löst das Problem, ohne das Standardverhalten der Betriebssysteme zu ändern, und ermöglicht viele weitere Optionen. Seien Sie nur vorsichtig, wenn das System für andere Benutzer freigegeben wird. Dadurch können private Dateien einer unerwarteten Zielgruppe ausgesetzt werden.
Gerlos

1
Ja. Ich war überrascht, dass das System Mount-Dienstprogramm diese Funktion nicht bietet. Alternativ können Sie die mapFunktionalität von bindfs verwenden, um Benutzer 502 einfach 1000 zuzuordnen, was möglicherweise sicherer ist und mehr von dem entspricht, was Sie beabsichtigt hatten.
Catskul

Da ich nicht den Ruf habe, einen Kommentar abzugeben, möchte ich nur darauf hinweisen, dass Catskuls Antwort einen kleinen Fehler enthält, der = fehlen sollte: sudo bindfs --map = 502/1000 / media / diskFoo ~ / myUIDdiskFoo
J. Simon van der Walt

1

Am Ende habe ich einen Linux-Benutzer mit der gleichen UID meines Mac OS X-Benutzers erstellt, aber er kann nicht jedes Verzeichnis in meinem Haus auf Mac HFS + Volume durchsuchen, da viele Dateien dem Mac-Benutzer "unbekannt", UID, gehörten 99 (siehe http://googlemac.blogspot.com/2007/03/user-99-unknown.html ).

Es scheint, dass sie dies getan haben, damit Sie Ihr Volume bereitstellen und lesen können, wenn Sie es an einen anderen Computer anschließen. Wenn ein normaler Benutzer sich die Dateien von UID 99 ansieht, sieht er sie als deren Eigentümer. Recht seltsam. Nur root sieht sie so wie sie sind.

Also habe ich in Mac Os X neu gestartet, mich mit einem anderen Benutzer mit Administratorrechten angemeldet und mit chown -R 502: 20 / Users / gerlos / * den Besitzer jeder Datei in meinem Haus geändert. Jetzt kann ich problemlos alles lesen.

Bemerkungen:

  • Das Standard-Kubuntu-GUI-Tool zum Erstellen neuer Benutzer unter Kubuntu 11.10 kann keine Benutzer mit einer UID von weniger als 1000 erstellen. Verwenden Sie stattdessen den Adduser auf dem Terminal.
  • Sie können Ihre Benutzer-UID mit dem Befehl "id" auf dem Terminal ermitteln.
  • Unter Mac OS X müssen Sie root sein, um den tatsächlichen Eigentümer der Dateien zu sehen. Erwarten Sie also unterschiedliche Ergebnisse, wenn Sie "ls -n / Users / gerlos" und "sudo ls -n / Users / gerlos" eingeben.

Dieser Unterschied in OSX zwischen dem "echten" Unix-Benutzer und dem vom Finder erkannten Benutzer bereitete mir große Kopfschmerzen. Einige Apps unter OSX können sich sogar seltsam verhalten (z. B. Dropbox synchronisiert Ihre Dateien nicht). Um Probleme zu vermeiden, melden Sie sich bei Ihrem OSX-System an, öffnen Sie ein Terminal und stellen Sie sicher, dass Ihr Unix-Benutzer alles besitzt, was Ihr OS X-Benutzer bereits besitzt. Vielleicht verstehe ich etwas nicht, aber meiner Erfahrung nach reicht die Verwendung der GUI nicht aus.
Gerlos

1

Eigentlich möchte ich etwas Ähnliches tun, wenn ich auf diese Frage stoße. Ich verstehe aus Ihrem ersten Beitrag, dass die angeforderte Mount-Option die Frage ist, welche Benutzer-UID anstelle der Standardeinstellung Ihres Linux-Systems (dh UID 1000) verwendet werden soll. Verwenden Sie stattdessen 502, den erwarteten Eigentümer des Dateisystems, das Sie bereitstellen möchten.

Ich habe dies in meiner eigenen Situation getestet und es hat großartig funktioniert, mit UID 99 für ein Dateisystem, das von meinen Systemen gemeinsam genutzt werden kann. Damit muss ich nicht mehr die Uids wechseln. Also danke fürs Teilen. Dies ist möglicherweise nicht mehr viel für Sie, kann aber jemand anderem helfen. Prost


1
Recht. Die beste Lösung besteht darin, UIDs und Berechtigungen in Ruhe zu lassen, Ihr HFS + -Dateisystem wie gewohnt bereitzustellen und dann Ihr Zuhause mithilfe von bindfs unter dem HFS + -Dateisystem bereitzustellen, sodass alles Ihrem Linux-Benutzer zu gehören scheint. Auf diese Weise müssen Sie niemals benutzerdefinierte UIDs verwenden und auch keine Berechtigungen im HFS + -Dateisystem ändern, sodass Sie das Standardverhalten in beiden Systemen beibehalten. Da Sie mit bindfs die Heimat jedes Benutzers erneut bereitstellen können, können Sie private Dateien auch in gemeinsam genutzten Systemen beibehalten und sie dennoch für Benutzer zugänglich halten.
Gerlos
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.