NFS Share mit User/Passwort im Terminal mounten

[HolgieF]

Hallo zusammen,

ich verzweifel bald. Ich versuche einen nfs share auf meinem NAS über das Terminal zu mounten. Das Problem: An diesem Share möchte ich mich mit einem bestimmten User anmelden, der auch nur in der Kommandozeile verwendet werden soll, also keine Anmeldung über den Finder und speichern der Anmeldeinformationen. Und ich bekomme es nicht gebacken. Ich habe meinen lokalen mountpoint, die Zielstruktur kann ich mit showmount -e $NAS ebenfalls sehen, aber ich finde einfach nicht heraus, wie ich die Informationen zu User und Passwort in das mount kommando packen soll. Das Kommando:

mount -t nfs $NAS:/$PFAD $MOUNTPOINT

funktioniert, ich kann auf den Share zugreifen. Aber nur mit dem normalen User, der auf diesem Share keine Schreibrechte hat. Für die Backupaktion brauche ich aber Schreibrechte auf dem Share (und auch nur für die Dauer des Backup). Versuche ich

mount -t nfs user:password@$NAS:/$PFAD $MOUNTPOINT

funktioniert das ebensowenig wie

mount -t nfs -o user=$USER,pass=$PASSWORT $NAS:/$PFAD $MOUNTPOINT

Daher die Preisfrage: Kennt jemand das korrekte Kommando und verrät es mir?

Danke schonmal!

 

[oneOeight]

Gibt es da kein mount_nfs?
Bin gerade nicht am Mac und kann nicht gucken.
Meist haben die direkten Kommandos feiner granulare Parameter.

 

[HolgieF]

Ich hab mir jetzt nochmal die man pages für mount und mount_nfs angeschaut, scheinbar gibt es da keine Option für user/passwort. Ich kann mir ja fast nicht vorstellen, dass das nicht gehen soll

 

[Johanna K]

Ich versuche einen nfs share auf meinem NAS über das Terminal zu mounten. Das Problem: An diesem Share möchte ich mich mit einem bestimmten User anmelden

Geht nicht, weil NFS nicht so funktioniert, wie du denkst.

Eine NFS-Freigabe wird allgemein, d. h. ohne Angabe eines Benutzernamens oder Passwortes eingebunden. Anschließend erfolgt eine Zuordnung von Mac-Benutzern zu NAS-Benutzern. Die Zuordnung erfolgt über die User-ID (die ID, die du beim Kommando 'id' als uid angezeigt bekommst). Der Mac-Benutzer hat auf der Freigabe dieselben Rechte wie der NAS-Benutzer mit derselben ID. Auch die Gruppen-IDs werden beachtet. Ab NFS Version 4 kann die Zuordnung auch über den Benutzernamen erfolgen, aber der Mac kann kein NFS 4, zumindest nicht bis High Sierra, der modernsten Mac OS X Version, mit der ich das probiert habe.

Du musst also für deinen gewünschten User auf dem NAS einen User mit derselben ID einrichten (oder umgekehrt auf dem Mac), und anschließend mit chown oder chmod die Rechte der Dateien und Verzeichnisse in der Freigabe passend setzen. Alternativ änderst du die User-ID von einem vorhandenen Benutzer (auf NAS oder Mac), musst dann aber daran denken, mit chown dies auch für alle Dateien, die ihm gehören, nachzuziehen (nicht nur in der Freigabe, sondern überall).

Das Sicherheitskonzept bei NFS geht davon aus, dass der Administrator nicht nur den Server, sondern auch alle Rechner im LAN unter seiner Kontrolle hat und alle anderen Anwender nur normale vom Admin angelegte User haben. Wenn das nicht gegeben ist, weil dein privater Mac im Netz ist, und du dich da als Root anmelden kannst, dann hast du volle Root-Rechte auf alle Dateien in allen NFS-Freigaben. Serverseitig lässt sich das einschränken, indem eine Freigabe auf vorgegebene IP-Adressen eingeschränkt wird. Dies ist aber nur geringer Schutz, weil man die IP seines Rechners leicht ändern kann. Sicher wird NFS in einem LAN mit bösartigen Nutzern erst, wenn eine Autorisierung über Kerberos eingebaut wird. Das habe ich aber noch nicht ausprobiert, und ich weiß nicht ob es mit dem Mac überhaupt funktioniert.

 

[HolgieF]

Nun, nachdem es mit nfs nicht geht, hab ich das Problem eben anders gelöst. Ist jetzt ein CIFS Share geworden. Da kann man sich per userasswort anmelden. Soll angeblich auch nicht langsamer sein. Und zumindest kommt mein normaler User da nicht ran. Muss also extra im Terminal gemountet werden.

Hintergrund: Ich möchte meine durchaus umfangreiche Bildersammlung nicht per Timemachine sichern, zumal ich hier keine Historie brauche. Das wird über rsync gemacht. Der unterschiedliche User hat einfach den Hintergrund, wenn ich mir tatsächlich mal eine Malware einfange die meine Daten verschlüsselt, möchte ich hinterher nicht unbedingt meine Bilder verlieren. K.A. ob sowas schon für MacOS im Umlauf ist, aber unter Windows war das eine Bedrohung.

 

[Johanna K]

zumal ich hier keine Historie brauche [...] wenn ich mir tatsächlich mal eine Malware einfange die meine Daten verschlüsselt

Es könnte aber auch sein, dass erst die Malware läuft, dann läuft das automatische Backup, und erst danach bemerkst du den Malwarebefall. Dann wäre die Malware zwar vielleicht nicht selbst an dein Backup rangekommen, du hättest aber trotzdem nur die verschlüsselten Dateien im Backup. Du benötigst also doch eine Historie, um für den Fall dort die letzte unverschlüsselte Version noch zu finden. Die Historie braucht bei den Bilddateien übrigens nur wenig Platz, da nur die Verzeichnisse mit jeder Version neu angelegt werden, die Dateien selbst aber nur, wenn sie sich geändert haben, ansonsten wird auf die Datei der vorangegangenen Version verwiesen (Hard Links). Bilddateien ändern sich idR. nicht (Lightroom, Darktable & Co. fassen die Originaldatei nicht an, sondern notieren nur die Änderungsschritte in einer kleinen Datei oder Datenbank).

Es gibt übrigens eine sicherere Methode gegen Malware:
Auf dem Mac läuft kein rsync. Stattdessen machst du eine Dateifreigabe (nur lesend!) des Bilderverzeichnisses (oder des Verzeichnisses, von dem du ein Backup haben willst). Das NAS mounted sich dieses Verzeichnis lesend. Der Backup-Job läuft dann auf dem NAS und schreibt das Backup in ein Verzeichnis, auf das der Mac keinerlei Zugriff hat (oder maximal lesend, aber dann muss die Einschränkung auf Leserechte zuverlässig auf dem NAS erfolgen). Dann kann eine Malware auf dem Mac die Backups nicht zerstören, weil auch du selbst von deinem Mac aus dies nicht könntest. Umgekehrt darf auch der Mac die Verzeichnisse nur mit Leserechte freigeben, damit Malware auf dem NAS nicht an die Originale kommt.
Ein lesender Rsync-Job auf dem NAS könnte das vielleicht auch tun (statt Verzeichnisse vom Mac zu mounten), aber ich weiß nicht, ob man auf dem Mac Rsync konsequent gegen Schreibrechte einschränken könnte.
Eine Historie brauchst du aber auch, also durch den Backup-Job auf dem NAS, s. o..

 

[roedert]

Das wird über rsync gemacht.

rsync benötigt doch gar kein Freigabe, sondern kann direkt über den ssh-Port auf zB das NAS schreiben ... user@host:/pfad/x/y/z

 

[HolgieF]

Es könnte aber auch sein, dass erst die Malware läuft, dann läuft das automatische Backup, und erst danach bemerkst du den Malwarebefall. Dann wäre die Malware zwar vielleicht nicht selbst an dein Backup rangekommen, du hättest aber trotzdem nur die verschlüsselten Dateien im Backup. Du benötigst also doch eine Historie, um für den Fall dort die letzte unverschlüsselte Version noch zu finden. Die Historie braucht bei den Bilddateien übrigens nur wenig Platz, da nur die Verzeichnisse mit jeder Version neu angelegt werden, die Dateien selbst aber nur, wenn sie sich geändert haben, ansonsten wird auf die Datei der vorangegangenen Version verwiesen (Hard Links). Bilddateien ändern sich idR. nicht (Lightroom, Darktable & Co. fassen die Originaldatei nicht an, sondern notieren nur die Änderungsschritte in einer kleinen Datei oder Datenbank).

Das kann passieren, aber das Backup läuft nicht automatisch, sondern wird per Hand nach Änderungen angestossen. Und wenn er anfängt alte Dateien neu zu schreiben, gehen logischerweise sofort die Alarmglocken an. So hab ich das bisher gehandhabt und es hat ganz gut geklappt die letzten Jahre.
Theoretisch würden sich bei den neueren Bildern tatsächlich nur die Sidecarfiles ändern. Die alten sind im DNG Format und da wird mWn die Änderung direkt in die Datei geschrieben. Man könnte LR auch rein mit der internen DB arbeiten lassen, aber ich nutze die Funktion Änderungen in die Sidecars, bzw. DNGs zu schreiben recht gerne. Hat mich jetzt beim Umstieg von Win zu Mac davor bewahrt auf dem Mac den ganzen Einstellungssums nochmal vornehmen zu müssen. Könnte man natürlich auch bei Bedarf schreiben, aber mir ist es so lieber.

Über Deinen Vorschlag muss ich mal ganz in Ruhe nachdenken. Klingt auf den ersten Blick garnicht so verkehrt. Danke