NFS Share in Linux Mint mit User & Passwort mounten

  • Hallo zusammen


    Ich möchte mich langsam von Windows verabschieden und versuche nun auf Linux Mint eine NAS Freigabe via nfs einzubinden, und zwar so, dass diese über die Berechtigungs-Verwaltung von QNAP geschützt ist.

    Dazu habe ich im Internet zwar einiges gefunden, aber auf Grund meiner Anfänger-Kenntnissen kann ich mit den Sqaush-Optionen und GID/UID nicht viel anfangen.

    Hat jemand schon Erfahrung damit und kann mir ein Konfigurations-Beispiel aufzeigen?


    lg

  • Na ja, wenn schon Linux mit Linux, dann bietet sich nfs an.

    Allerdings ist das unter Linux anders, als bei Windows.

    bergherr : mounten darf i.d.R. nur der root bzw. ein User mit sudo Rechten.

    Die Freigabe erfolgt auf ein Netzwerk oder einzelne Hosts, die Rechte für Benutzer musst Du unter Linux im Filesystem vornehmen.


    Ich würde das zunächst erst mal testen, bevor Du dann mit weitern Optionen hantierst. UID/GID ist übrigens wie unter Windows, da hast Du entsprechende SIDs.


    Gruss

  • Die Freigabe von NFS auf Host Ebene, find ich aber ein bissle "Schmal" wenn man ne wirkliche Zugriffskontrolle machen will. (Rechte auf Nutzer + Freigabeebene)


    NFS hat sicherlich eine Daseinsberechtigung, nur halt nicht bei der Voraussetzung... find ich.

  • SMB war eigentlich auch meine erste Wahl. Dann allerdings stellte ich fest, dass die Performance im Vergleich zu Windows doch recht bescheiden war: zB ein Ordner mit mehreren Tausend Fotos zu öffnen dauerte eine gefühlte Ewigkeit unter Linux Mint (Nemo). Ein Versuch mit NFS war deutlich performanter.


    Zugriffsschutz bei NFS über Host / Netzwerk ist für mich nicht ausreichend.

    Deshalb bin ich auf https://wiki.qnap.com/wiki/Mounting_an_NFS_share_on_Ubuntu gestossen, wo mit username und passwort verbunden wird. Funktioniert bei meiner Freigabe aber nicht.


    SMB wäre für mich schon eine Option, wenn die Performance besser wäre.


    lg

  • Das in dem Link hat nicht wirklich was mit dem Zugriffsschutz zu tun.

    Das ist nur der mount Befehl. Wie gesagt, i.d.R. kann nur root mounten oder sudoers, aber wenn gemountet ist, kann jeder zugreifen, der die entsprechenden Filesystemrechte hat.

    Außerdem ist ubuntu 8.x etwa so aktuell wie QTS 4.0 ;).


    Gruss

  • Bei NFS muss man darauf achten, dass die UserIDs und GroupIDs der Benutzer auf dem Client und Server identisch sind.

    Einmal editiert, zuletzt von Eraser-EMC2- () aus folgendem Grund: Korrekturen

  • Der Grundgedanke bei NFS und Unix (Linux) ist, dass der Administrator nicht nur den Server, sondern auch alle Clients (PCs u. A.) unter seiner Kontrolle hat (denk an Firmennetzwerke). Die Authentifizierung und Rechteprüfung wird auf den Client verlagert. Deswegen wird beim Mounten von NFS auch kein Passwort verlangt, sondern die Freigabe kann immer gemountet werden. Aber ein Nutzer kann sich auf seinem Client nur unter einem Benutzernamen anmelden und hat damit nur Zugriff auf die Dateien im Netzwerk, die auch für seinen Benutzer passende Rechte haben.


    Sobald aber auch nur ein einziger PC nicht unter der Kontrolle des Admins steht, wird dieses Konzept ausgehebelt, da in dem Moment der Besitzer dieses Rechners beliebige User-Ids oder Namen verwenden kann, insbesondere auch die von Root, und damit kommt er an alle Dateien aller NFS-Freigaben ran.


    Um das Sicherheitsproblem zu begrenzen, ist es möglich, den Zugriff auf eine NFS-Freigabe auf einzelne IPs oder IP-Bereiche zu begrenzen (das geht auch mit Qnap leicht einzustellen). Dies wird aber nur deine Oma abhalten, da es leicht ist, dem eigenen Rechner eine andere IP zu verpassen. Immerhin lassen sich darüber Zugriffe von außerhalb oder über VPN unterbinden.


    Die sichere Möglichkeit, NFS-Freigaben in einem potentiell unsicheren Netz zu betreiben, besteht in der Authentifizierung über Kerberos. Dann hat man das Schutzniveau von SMB. Allerdings ist dies nicht so trivial, da es nicht in qts zusammengeklickt werden kann. Ich wollte dies immer schon mal machen, nicht weil ich es brauche (habe keine böswilligen Nutzer im Netz), sondern weil ich lernen will, wie es geht, aber das steht auf der Liste der immer wieder aufgeschobenen Vorhaben.


    Bei NFS muss man darauf achten, dass die UserIDs und GroupIDs der Beutzer auf dem Client und Server identisch sind.

    Ab NFS Version 4 ist die Zuordnung auch über Benutzer- und Gruppenname möglich, d. h. dann dürfen die IDs unterschiedlich sein.

  • Danke für die ausführliche Erklärung der NFS-Philosophie.

    Somit ist für mein Fall klar, dass NFS nicht zum Einsatz kommt. Aus Sicherheitsgründen.


    SMB:

    Die festgestellten Performance-Schwächen bei Ordnern mit sehr vielen Dateien (Fotos), worauf sind diese zurückzuführen? Liegt das evt nur am Dateimanager Nemo oder an der Einbindung via fstab? Oder sogar an der Distribution Mint?


    Was habt ihr für Erfahrungen mit SMB unter Linux gemacht?


    lg

  • Hmm, ich käme nie auf den Gedanken, bei 2 Linux-Systemen SMB zu verwenden.

    Ist schon länger her, dass ich mal auf einem Linux-PC ein SMB-share eingebunden habe, aber wenn ich mich recht erinnere, mußte man da das SMB-Passwort bei einem automatischen mount in einer Datei im Klartext speichern, was ja nu generell Banane ist.

    Wieso hast Du mit dem Sicherheitskonzept von NFS ein Problem? Ich würde doch erwarten, dass sowohl das NAS als auch Deine Linux-Büchse beide unter Deiner Kontrolle sind und sonst nur vertrauenswürdige Sysadmins da sind. Dann stellt NFS kein Problem dar und ist wesentlich performanter, wie du shcon selbst rausgefunden hast.

  • Ich habe mir gerade eine Freigabe per SMB auf einem raspBerry Pi gemountet.

    Im Share sind Dutzende Unterordner und mehrere 10K Dateien mit Bildern.

    Das läuft wie Schmitz Katze, Die Bilder haben unterschiedliche Größen, aber so gut wie keinerlei Wartezeiten kann ich feststellen.

    Wobei ich den Pi aber auch nur auf der Konsole benutze und Kommandos wie z.B. ls absetze. Ansehen kann ich mir die Bilder nicht, ich habe keine grafische Oberfläche installiert.


    Gruss

  • Liegt das evt nur am Dateimanager Nemo oder an der Einbindung via fstab? Oder sogar an der Distribution Mint?

    Es kann am Dateimanager liegen. Dies wäre meine erste Anlaufstelle für Versuche. Hier kann leicht eine Alternative ausprobiert werden.


    Es kann auch an den SMB-Treibern und damit letztlich an der Linux-Distribution liegen. Hier ist es aber schwierig, eine Alternative auszuprobieren.


    Eventuell gibt es mit Jumbo-Frames Probleme, oder es geht mit Jumbo-Frames schneller. Das kann man auch leicht probieren.


    An der Einbindung via fstab liegt es mit Sicherheit nicht. Das betrifft nur den Moment des Mountens selbst.

    aber wenn ich mich recht erinnere, mußte man da das SMB-Passwort bei einem automatischen mount in einer Datei im Klartext speichern, was ja nu generell Banane ist.

    Die Anmeldedaten ("Credentials") können in fstab selbst oder in einer beliebigen anderen Datei liegen, und beide können das Recht 600, d. h. nur für Root lesbar, haben. Damit kann außer Root niemand das Passwort lesen.

    Soll die Freigabe erst bei Login eines Benutzers gemountet werden, dann kann das Passwort auch aus dem Passwort-Store (z. B. Schlüsselbund beim Mac) kommen und ist damit nur für den Benutzer lesbar, der auch mountet - also wie bei Windows/Mac.

    Ich würde doch erwarten, dass sowohl das NAS als auch Deine Linux-Büchse beide unter Deiner Kontrolle sind und sonst nur vertrauenswürdige Sysadmins da sind. Dann stellt NFS kein Problem dar

    Es reicht ein einziger Rechner, der nicht unter Kontrolle der Admins ist, sei es das Handy des nichtsnutzigen Sohnes einer Bekannten, sei es ein mit Viren verseuchter oder gehackter PC, so dass alle Dateien aller NFS-Freigaben potentiell abgreifbar sind.


    Daher bin ich nicht deiner Meinung. Hier hat NFS ein klares Sicherheitsdefizit und ist mMn. etwas aus der Zeit gefallen. Erst mit Kerberos sieht das wieder gut aus für NFS.

    und ist wesentlich performanter,

    Auch wenn nicht direkt zum Thema: Am Mac sind sowohl SMB als auch APF ein Stück schneller als NFS. Unter Linux kann das anders aussehen. Nur als Bemerkung, damit "NFS ist schneller" nicht verallgemeinert beim Leser hängen bleibt.


    (Ich selbst nutze übrigens auch NFS, in einem Falle, weil ein Eclipse-Plugin nicht mit SMB und AFP funktioniert, wohl aber mit NFS, und um die NAS-Verzeichnisse auf der dort laufenden Linux-VM einzubinden - in letzterem Falle dürfte die Begrenzung auf deren IP wohl sogar genug Schutz bieten.)


    EDIT:

    Wobei ich den Pi aber auch nur auf der Konsole benutze und Kommandos wie z.B. ls absetze.

    Das ist nicht vergleichbar. Bei ls muss genau ein Verzeichnis gelesen und übertragen werden, der Dateimanager muss hingegen jede Bilddatei lesen, um eine Vorschau zu erzeugen. Bei tausend Bildern im Verzeichnis hat der Dateimanager daher ganz grob 1000mal so viele Zugriffe.

  • Es reicht ein einziger Rechner, der nicht unter Kontrolle der Admins ist, sei es das Handy des nichtsnutzigen Sohnes einer Bekannten, sei es ein mit Viren verseuchter oder gehackter PC, so dass alle Dateien aller NFS-Freigaben potentiell abgreifbar sind.

    Für sowas gibt es Gast-Netzwerke...

    Die Anmeldedaten ("Credentials") können in fstab selbst oder in einer beliebigen anderen Datei liegen, und beide können das Recht 600, d. h. nur für Root lesbar, haben. Damit kann außer Root niemand das Passwort lesen.

    Das das ist leider ein großes Sicherheits-Problem. Man speichert keine Passwörter in Klartext in irgendeiner Datei, egal ob die nur für root lesbar ist (der ja auch kompromittiert werden kann).

    Daher ist der automount eines SMB share ebenfalls ein Sicherheitsproblem und sicher nur über manuelles Einhängen zu realisieren oder eben einen Schlüsselbund etc.

    Einmal editiert, zuletzt von UdoA ()

  • Für sowas gibt es Gast-Netzwerke...

    Was aber nichts nützt, wenn ein Rechner virenverseucht oder gehackt ist, und auch in Firmen oder Familien kann man gelangweilte Mitarbeiter oder Kinder haben, die bereits im eigentlichen LAN sind und somit Serverzugriff haben.

    Das das ist leider ein großes Sicherheits-Problem. Man speichert keine Passwörter in Klartext in irgendeiner Datei,

    Korrekt. Allerdings kann nur der Root-Admin diese Datei lesen, und für Freigaben, die schon bei Systemstart eingebunden werden, kennt er ohnehin das Passwort. Freigaben, die nur einen Benutzer etwas angehen, sollten erst bei Login eingebunden werden, und dann kann das über einen Keystore oder wie das bei Linux heißt geschehen.


    Ich sehe die Sicherheit von NFS ohne Kerberos als wesentlich schlechter an, denn da braucht ein Angreifer sich überhaupt nicht die Mühe zu machen, an irgendwelche lesegeschützten Dateien zu kommen, sondern kann, so er denn im LAN ist, direkt auf die NFS-Freigaben zugreifen. Das ist geradezu trivial.

  • ...

    Das ist nicht vergleichbar. Bei ls muss genau ein Verzeichnis gelesen und übertragen werden, der Dateimanager muss hingegen jede Bilddatei lesen, um eine Vorschau zu erzeugen. Bei tausend Bildern im Verzeichnis hat der Dateimanager daher ganz grob 1000mal so viele Zugriffe.

    Ich habe jetzt auf dem Pi den grafischen Desktop aktiviert und mich per VNC darauf verbunden

    Die Auflistung und das Aufrufen der Dateien ist nur unwesentlich langsamer als an meinem Windows 10 PC. Mit den Thumbnails dauert es wenig, das stimmt.

    Aber ansonsten ist der Zugriff bei mir absolut ok.


    Gruss