[GELÖST!] Bitte um Hilfe beim Mounten

[DocCyber]

Guten Tag zusammen.

Leider sehe ich unter /mnt/nas nicht die freigegebene externe Festplatte, die als nas an meiner Fritzbox hängt.
Unter Windows funktioniert die Freigabe, d.h. auf Seite der Fritzbox scheint alles korrekt eingerichtet zu sein. (s. Screenshots)

/home/pi/.smbcredentials  enthält

Code Auswählen Erweitern


username=benutzer
password=kennwort


/etc/fstab enthält

Code Auswählen Erweitern


//192.168.178.1/nas/WD-5000BEVExternal-01       /mnt/nas        cifs    credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,sec=ntlm  0       0

Der Code in fstab sollte für den User pi funktionieren, aber es klappt nicht (meine Platte wird unter /mnt/nas nicht angezeigt):

Code Auswählen Erweitern


RPi3:~ $ ls /mnt/nas
RPi3:~ $


Code Auswählen Erweitern


RPi3:~ $ grep pi /etc/passwd
pi:x:1000:1000:,,,:/home/pi:/bin/bash
RPi3:~ $


Code Auswählen Erweitern


-RPi3:~ $ grep fhem /etc/passwd
#fhem:x:999:20::/opt/fhem:/bin/false
fhem:x:999:20::/opt/fhem:/bin/bash
RPi3:~ $


Zwei Fragen hierzu:
1. Kann mir jemand sagen, was ich falsch gemacht habe?
2. Wie muss der Eintrag in fstab aussehen, wenn sowohl pi als auch auch fhem lesen und schreiben sollen dürfen?
    Ich vermute, dass dafür fhem und pi in eine Gruppe gehören müssen, die z.B. nasusers heißen soll.

[Otto123]

Hi,

Code Auswählen Erweitern

//192.168.178.1/nas/WD-5000BEVExternal-01       /mnt/nas        cifs    credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,sec=ntlm  0       0

zu 1. reduzierter Gegenvorschlag

Code Auswählen Erweitern

//192.168.178.1/nas/WD-5000BEVExternal-01   /mnt/nas cifs noauto,users,credentials=/home/pi/.smbcredentials 0 0

zu 2. die Datei .smbcredentials muss lesbar sein, siehe dazu meine Notizen.

Welche SMB Version unterstütz die NAS?
aktuelles Fritz OS unterstützt auch SMBv3

Ich denke sec=ntlm  ist fehl am Platz!

Gruß Otto

[DocCyber]

Hallo Otto,

ich hatte lange nichts mehr von dir gehört, aber du hast mir wie (fast) immer helfen können. Super, vielen Dank.
Besonders hilfreich waren deine zitierten Notizen!

Zusammengefasst habe ich die Credentialsdatei jetzt unter /usr angelegt, so dass alle Benutzer das nas lesen und schreiben können.
Die Zugangsdaten stehen jetzt also in /usr/.smbcredentials

In /etc/fstab steht dafür

Code Auswählen Erweitern


//192.168.178.1/nas/WD-5000BEVExternal-01       /mnt/nas        cifs    noauto,users,credentials=/usr/.smbcredentials 0 0


Nach manuellem Mounten mit

Code Auswählen Erweitern

mount /mnt/nas
läuft es jetzt für beide Benutzer pi und fhem. 

Zum Schluss noch eine Frage:
Geht es auch mit automatischem Mounten? Dazu noauto weglassen? Oder durch auto ersetzen?

[Wernieman]

DIe Datei /usr/.smbcredentials muß doch nicht durch den User, sondern nur durch root lesbar sein, oder? So kannst Du auch gleich das Passwort "jedem" Mitteilen ...

Fürs automatische mount das "noauto" und "user" weglassen.

[Otto123]

@Werner interessant, muss ich probieren. Ich weiß, es funktioniert bei davfs2 so. Aber da muss der User in der Gruppe davfs2 sein. Sorry, ich kannte es nicht anders.

@DocCyber automatisch mounten "lehne" ich irgendwie ab. Aber ja, das geht sicher. Ich meine: beim Systemstart geht das bei cifs nicht einfach so - Abhängigkeiten vom Netzwerk... Die meisten verwenden dann automount.
Ich verarbeite den mount im Script, da weiß ich ob der mount erfolgreich war und muss nicht separat prüfen. Wenn ich den mount nicht mehr brauche wird wieder getrennt. Vielleicht paranoid

[Wernieman]

Nicht paranoid, sondern fürs Backup sinnvoll. Mache ich dort auch so ...

[DocCyber]

DIe Datei /usr/.smbcredentials muß doch nicht durch den User, sondern nur durch root lesbar sein, oder? So kannst Du auch gleich das Passwort "jedem" Mitteilen ...

@Wernieman
Würdest du mir mitteilen, wie die Lösung dann aussehen muss? Die beiden User fhem und pi sollen die externe Platte lesen und beschreiben dürfen.

[Wernieman]

Probiere doch mal, der Datei andere Rechte zu geben und dann zu mount/umount

z.B.:

Code Auswählen Erweitern

chown root:
chmod 776

Wenn das funzt (bin mir aktuell nicht sicher, ob sogar in diesem Falle nicht ein Test mit reboot gut währe), dann die chmod so Einrenzen, das nur root lesen darf. Berechtigung kannst Du gut mit ls -lha prüfen ...

Da die die Berechtigung weist, kannst Du nachjedem Schritt wieder zurück. Da ich aktuell aber kein cifs (samba) mount hier habe, kann ich es nicht für Dich testen.

[DocCyber]

Probiere doch mal, der Datei andere Rechte zu geben

Ich bin keinesfalls ausreichend erfahren in Linux, aber nach meiner Meinung ist root bereits der Owner, oder liege ich daneben?

Code Auswählen Erweitern


RPi3:~ $ cd /usr
RPi3:/usr $ ls -l .smbcredentials
-rw-r--r-- 1 root root 47 Mär 24 17:21 .smbcredentials
RPi3:/usr $


[Wernieman]

Ja, das stimmt, aber wie Du siehst steht dort RW--R--R

Es gibt R, W und X
R: Lesbar (Read)
W: Schreibar (Write)
X: Ausführbar (Execute), bei Directorys auch als "einspringbar" bezeichnet.

Dann sind die 3 Positionen noch Wichtig.
Zuerst User (u), dann Group (g), dann Jedermann (a)

Also hier arf der User root lesen und schreiben, die Gruppe root darf lesen und jedermann darf lesen .... und genau das letzte ist "nicht gut".

besser:
chmod o-r <Dateiname>

Was zum lesen:
https://de.wikipedia.org/wiki/Chmod
https://wiki.ubuntuusers.de/chmod/
https://wiki.ubuntuusers.de/Rechte/

[DocCyber]

@Wernieman

Das ist einleuchtend.
Eigentlich sollte es nicht notwendig sein, nach dem Ändern der .smbcredentials einen reboot durchzuführen, sondern nur, wenn /etc/fstab geändert wird, denn nur letztere hat einen Einfluss auf das Dateisystem. Nach meinen Überlegungen ist es logisch, dass beim Mounten lediglich die Datei .smbcredentials neu gelesen wird.
Demnach habe ich folgendes gemacht:

Code Auswählen Erweitern


RPi3:/usr $ sudo umount /mnt/nas
# nur root soll lesen und schreiben dürfen
RPi3:/usr $ sudo chmod 600 .smbcredentials
RPi3:/usr $ sudo mount /mnt/nas # Externe Platte ist wieder sichtbar
RPi3:/usr $ sudo systemctl stop fhem
RPi3:/usr $ sudo reboot


dann

Code Auswählen Erweitern


-RPi3:~ $ mount /mnt/nas
error 13 (Permission denied) opening credential file /usr/.smbcredentials # user pi darf .smbcredentials nicht lesen
RPi3:~ $ sudo mount /mnt/nas # Externe Platte ist wieder sichtbar
RPi3:~ $


Alles prima! 
Danke an @wernieman und @otto123 für die Hilfestellungen

[Otto123]

Aber damit geht jetzt mounten nicht mehr als user!? Genau das würde ich nicht wollen!
Klar kann man es so einschränken, aber bei einem solchen System: es gibt fhem und pi und sonst niemanden!
Entweder lässt man die user alle mounten, oder man schränkt es auf einen user/gruppe ein.
Aber auf root einschränken und alle machen dann wieder Dünnbrettbohrer sudo - ist mMn am Ziel vorbei!

Bei davfs2 ist das genauso wie Werner vermutet: dort darf nur root die credentials lesen und alle in der Gruppe davfs2 dürfen mounten. Aber bei cifs geht das scheinbar (war bisher mein Kenntnissstand) nur darüber, dass die user die mounten können sollen auch die credential Datei  lesen können müssen.

Mann könnte jetzt also eine Gruppe cifs einführen und denen Leserecht geben? Oder man legt die credentials (als owner) einfach im HomdeDir des Users ab, der mounten können soll.

Allerdings gibt es tausend unterschiedliche und mMn unübersichtliche Wege das alles zu konfigurieren und meistens reden wir von einem Backup Pfad auf dem das abgelegt wird, was der User eh schon lesen konnte.
Der normale Anwender ist ja immer froh wenn es geht, meistens hat er einen Weg kopiert, den er nicht kapiert hat

[DocCyber]

hmmm...
Nach meiner Meinung kann man das aus zwei Perspektiven betrachten, nämlich aus der prinzipiellen und der praktischen Perpektive.

Aus der fhem-Praxis würde ich dir Recht geben, Otto. Es gibt tatsächlich nur pi und fhem als Benutzer, und die sollten beide lesen können.
Prinzipiell neige ich aber eher zu Werners Ansicht, dass es nämlich wenig Sinn hat, eine Credentials-Datei für jedermann einsehbar zu machen.

Man kann aber, so glaube ich, auch ein Passwort für root vergeben. Damit wäre zumindest die inflationäre Verwendung von sudo deutlich eingeschränkt.

[Otto123]

Man kann aber, so glaube ich, auch ein Passwort für root vergeben. Damit wäre zumindest die inflationäre Verwendung von sudo deutlich eingeschränkt.

das macht es meiner Meinung nach nicht besser, aber das hängt viel von persönlichen Arbeitsweisen ab. Ich arbeite gern mit sudo - aber eben interaktiv und nicht als user fhem.

Du musst jetzt wissen wie Du es handhaben willst. Ich würde den user fhem mounten lassen wollen, also müsste dieser die credentials lesen können. Für fhem oder cifs gibt es keine extra Gruppe, also müsste man eine erschaffen. Das wäre sicher der richtige Weg. Ich denke dabei ja auch immer: ich möchte es jemanden erklären können wie es funktioniert - ohne das der mit den Augen rollen muss

Vorschlag

Code Auswählen Erweitern

sudo -s <<'EOI'
  datei='/usr/.smbcredentials'
  addgroup cifs
  usermod -aG cifs fhem
  usermod -aG cifs pi
  chown root:cifs ${datei}
  chmod 640 ${datei}
EOI

Nach Neuanmeldung funktioniert der mount für den User ohne sudo

[DocCyber]

    Für fhem oder cifs gibt es keine extra Gruppe, also müsste man eine erschaffen. Das wäre sicher der richtige Weg.

Dann lag ich eingangs ja gar nicht so falsch, ohne dass ich allerdings wusste, wie man das realsiert

    Ich vermute, dass dafür fhem und pi in eine Gruppe gehören müssen, die z.B. nasusers heißen soll.

Ich denke dabei ja auch immer: ich möchte es jemanden erklären können wie es funktioniert - ohne das der mit den Augen rollen muss

Guter Grundsatz! 

Code Auswählen Erweitern

sudo -s <<'EOI'
  datei='/usr/.smbcredentials'
  addgroup cifs
  usermod -aG cifs fhem
  usermod -aG cifs pi
  chown root:cifs ${datei}
  chmod 640 ${datei}
EOI

Probiere ich aus - looks like the best of two worlds 

[Wernieman]

fstab muß aus Historischen Gründen lesbar für alle sein (Jedenfalls meines WIssens, kann sich mittlerweile geändert haben). Deshalb arbeitet man eben gerne mit einer credential-Datei, da diese eben "versteckt" werden kann.

Wobei ich es sowieso nicht gut finde, wenn so etwas auf einem System "rumliegt" ... aber was soll man dagegen machen?

[DocCyber]

Ich muss nochmal hierher zurückkehren, obwohl ich dachte, dass alles funktioniert

Naja dann ist /mnt/nas/raspberry/fhem/backups quasi "falsch" gemountet. pi hat Rechte alle anderen keine.

Das stimmt - aber das will ich so natürlich nicht haben.

Das Mounting habe ich im Grunde so gemacht, wie du es hier vorgeschlagen hattest - mit kleinen Anpassungen:

Probiere ich aus - looks like the best of two worlds 

Die externe Platte wird unter /mnt/nas eingebunden.

Code Auswählen Erweitern

//192.168.178.1/nas/WD-5000BEVExternal-01       /mnt/nas        cifs    noauto,users,credentials=/usr/.smbcredentials 0 0
Zugangsdaten stehen in ./usr/.smbcredentials
Es muss manuell gemounted werden.

Es gibt eine Gruppe nasusers mit den Mitgliedern pi und fhem. Beide können die Credentials lesen.

Code Auswählen Erweitern


RPi3:~$ ls -l /usr/.smbcredentials
-rw-r----- 1 root nasusers 47 Mär 24 17:21 /usr/.smbcredentials



Aber: obwohl die Gruppe nasusers Schreibrechte in /mnt hat, kann pi dort schreiben, fhem aber nicht. Verstehe ich nicht.

Code Auswählen Erweitern


-RPi3:~$ ls -l /mnt
insgesamt 4
drwxrw-r-- 2 pi nasusers 4096 Apr  4 16:41 nas


Also ein

Code Auswählen Erweitern

nano /mnt/nas/test.txt lässt sich als pi speichern, aber nicht als fhem

[Otto123]

drwxrw-r--

Da fehlt ein x für die Gruppe? Damit darf die Gruppe nicht ins Verzeichnis wechseln - oder sehe ich das falsch?

Der der mountet steht "vorn" und darf alles ...

[DocCyber]

Ach so ...
Aber das Schreiben von Dateien auf das nas wird doch der Gruppe durch w erlaubt?!?!

Ich dachte bislang immer, dass x nur für das Ausführen von executable files steht... 

[Otto123]

bei einer Datei ja. Bei einem Verzeichnis bedeutet x man darf hineinwechseln. Wenn er nicht hinein darf, darf er auch nicht schreiben. Er hat Stift und Papier - aber die Tür ist zu.
https://www.howtoforge.de/anleitung/was-ist-umask-unter-linux/

[Wernieman]

Ergänzend zu Otto:
Deshalb dürfen alle den "Inhalt" des Direktories lesen (r), aber nicht schreiben oder "reinwechseln".

Also Aufgeschlüsselt

d rwx rw- r--
^⁻ Direktory
      ^- User darf lesen, schreiben und Wechseln (da Direktory)
           ^- Gruppe darf lesen und schreiben, aber nicht reinwechseln (z.B. Bestehende Datei beschreiben, aber nicht neue eintragen)
                 ^- Alle dürfen lesen, sehen also die Dateinamen des Direktories, aber dürfen weder schreiben noch reinwechseln

[DocCyber]

und schon wieder etwas dazu gelernt...

Danke euch, Jungs.