[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]

username=benutzer
password=kennwort

/etc/fstab enthält

Code: [Auswählen]

//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]

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


Code: [Auswählen]

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


Code: [Auswählen]

-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]

//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]

//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]

//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]

mount /mnt/naslä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]

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]

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]

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]

-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]

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]

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