Samba Probleme seit Update

[MegaV0lt]

Bei mir klappt das mit dem Mounten über die fstab. Hast Du das auch an das Ende der Datei gestellt? Vielleicht ein Timingproblem.
Du könntest den Mountbefehl auch in die /etc/rc.local schreiben. Ein "mount /mnt/root_fs" würde reichen, a die Angaben ja alle in der fstab stehen.

Bei mir ist "/" eine CompctFlash-Karte, von der der ThinCliens bootet.

Gibt es ein Log?

[willybauss]

Danke. Zusätzlich in die /etc/rc.local eintragen hat geholfen.

Bei mir ist / eine MicroSD-Karte, von der der Raspi bootet.

[willybauss]

Noch was: bei meinem zweiten Raspi hatte auch das nicht geholfen. Das Problem lag dann auf der Windows-Seite. Trotz "Netzlaufwert trennen" blieb die alte Verbindung, obwohl getrennt, dem System unter dem alten Namen bekannt. Erst der Start einer Kommandozeile und dort "net use" zeigte, dass da noch was war. Das löschte ich dann mit

Code: Alles auswählen

net use \\Rechnername\Freigabe /delete

Danach konnte ich das neue Netzlaufwerk erfolgreich verbinden.

[willybauss]

Da ergibt sich jetzt doch noch ne Folgefrage:

Ich habe zwar root freigegeben und auf einen Laufwerksbuchstaben in Windows gemappt, aber ich möchte zusätzlich ein Unterverzeichnis auf einen anderen Laufwerksbuchstaben mappen. Das klappt aber nicht. Ich habe es in die smb.conf eingetragen als

Code: Alles auswählen

[optfhem]
        comment = optfhem
        path = /opt/fhem
        read only = No
        create mask = 0644
        guest ok = Yes
        locking = No

... und anschließend Samba neu gestartet. Windows nimmt beim Verbinden des NEtzlaufwerks die User/Passwort-Kombination nicht an.

Was mache ich falasch?

[MegaV0lt]

Versuche mal das "guest ok = Yes" auszukommentieren...

[willybauss]

Hilft leider nicht.

Was mich wundert: ich komme im Explorer auf die Freigabe mit

Netzwerk - RASPI - optfhem

Auch alle Unterordner sind verfügbar. Nur den Laufwerksbuchstaben bekomme ich nicht hin. Ist dann das Problem eher auf der Windows-Seite?

[TomL]

Hast Du schon mal im Commandline-Fenster einen simplen "net use" probiert? Da müsstest Du ggf. dann Fehlermeldungen sehen, wenns nicht klappt. Du musst Laufwerksbuchstabe, IP und Freigabename anpassen und {Pwd} durch das richtige Passwort ersetzen. UserDomain und Name können bleiben. Persistent=yes bedeutet, dass es beim nächsten Systemstart automatisch verbunden werden soll.

Code: Alles auswählen

net use v: \\10.20.30.2\Daten {Pwd} /user:%USERDOMAIN%\%USERNAME% /persistent:yes

Um zu sehen, was UserDomain und Username enthält, gibst Du ein:

Code: Alles auswählen

echo %USERDOMAIN%
echo %USERNAME%

[willybauss]

Klasse, geht - DANKE !!!
Geht sowohl bei "normalem Verzeichnis als auch bei einem gemounteten USB-Stick.

Was ich aber nicht verstehe:

Code: Alles auswählen

echo %USERDOMAIN%
echo %USERNAME%

sagt mir, dass die Verbindung mit meinem Windows-Login erfolgt, obwohl ich bei der Freigabe in der smb.conf kein "guest ok = yes" gesetzt hatte. Neu erstellte Dateien haben nun den Owner "root". Mal schauen, ob ich das noch auf "force user = pi" oder so ähnlich umbiegen kann.

[TomL]

Mal schauen, ob ich das noch auf "force user = pi" oder so ähnlich umbiegen kann.

Ich würde den User PI ganz löschen und unbedingt auch verhindern, dass er (falls ers tut) nen Auto-Login durchführt. Und wenn Du ihn löscht, musst Du vorher unbedingt "root" ein Passwort vergeben und Dich selber als normalen User anlegen, mit Name und einfallsreichem (!) Password.

Ich halte den eingerichteten und allgemein bekannten User PI mit womöglich noch vorhandenem Default-Password für ein Sicherheitsrisiko. Ich würde mich mit meinem Namen anmelden, und zwar mit eigenem Password und dann mit "su" unter Verwendung eines wiederum eigenen Passwortes zu "root" werden, wenn ich Änderungen am System durchführen möchte. Den default-User "Pi" braucht man eigentlich nicht.

j.m.2.c.

[willybauss]

Klingt einleuchtend, danke.

Aber warum ich mich von Windows aus mit einem nicht existenten Usernamen anmelden kann verstehe ich immer noch nicht (sh. mein letzter Beitrag).

[willybauss]

Bei mir ergibt sich jetzt doch nochmal eine Nachfrage/ein Problem(?).

/etc/fstab:

Code: Alles auswählen

/  /mntroot/root_fs  auto  defaults,rbind,nofail,noatime,nodiratime  0  0
/media/usb /mntUSB auto  defaults,rbind,nofail,noatime,nodiratime,users,rw  0  0

/etc/rc.local:

Code: Alles auswählen

mount /mntroot/root_fs
mount /mntUSB

Damit sollten doch eigentlich die beiden Verzeichnisse
/mntUSB/IP-Cam
und
/mntroot/root_fs/mntUSB/IP-Cam
identisch sein, richtig?

Die Inhalte sind aber unterschiedlich. Wieso?

[willybauss]

weiß Niemand die Antwort?

[DeletedUserReAsG]

Du hast leider vergessen zu schreiben, was genau unterschiedlich ist.

[willybauss]

das IP-Cam Verzeichnis wird automatisch von der Webcam mit aktuellen Bildern befüllt. Das Verzeichnis

Code: Alles auswählen

/mntUSB/IP-Cam

ist leer, im Verzeichnis

Code: Alles auswählen

/mntroot/root_fs/mntUSB/IP-Cam

sind die Bilder sichtbar.

Eigentlich sollten sie ja auch in /mntUSB/IP-Cam zu sehen sein.

[TomL]

/etc/fstab:

Code: Alles auswählen

/  /mntroot/root_fs  auto  defaults,rbind,nofail,noatime,nodiratime  0  0
/media/usb /mntUSB auto  defaults,rbind,nofail,noatime,nodiratime,users,rw  0  0

Ich kann hier nicht erkennen, ob es sich tatsächlich immer um das gleiche Device handelt. Im ersten mount beziehst Du Dich mit "/" auf das root-Dir, im zweiten Mount beziehst Du Dich auf den mountpoint "/media/usb", der anscheinend als Device herhalten soll. Wenn es sich um ein lokales Verzeichnis handelt, würde ich eher einen "bind" verwenden. Oder ist dahin noch ein weiteres anderes Device gemountet... leider ist Deine fstab ja nicht vollständig angegeben. Aber wenn ich ehrlich bin, kommt mir beides ziemlich suspekt vor. Warum wird "/" überhaupt nach /mntroot/root gemountet...?... warum reicht nicht einfach "/" ohne mount?

Wie heissen die Devices für diese beiden Mounts? Ist es beides Mal wirklich das gleiche Device? Schau dir das mal an, mit:

Code: Alles auswählen

blkid -o list

[willybauss]

Warum ich "/ /mntroot/root_fs" verwende steht in diesem Thread weiter oben: der Schreibzugriff von Windows aus ist nicht möglich, wenn man ein Netzlaufwerk direkt auf / mountet. Es geht aber, wenn das Netzlaufwerk nach /mntroot/root_fs gemountet wird.

Deshalb dachte ich, wenn "/" und "/mntroot/root_fs" eigentlich dasselbe sind, dann sollten ja auch "/mntUSB/IP-Cam" und "/mntroot/root_fs/mntUSB/IP-Cam" dasselbe sein.

blkid liefert:

Code: Alles auswählen

blkid -o list
device                     fs_type     label        mount point                    UUID
-----------------------------------------------------------------------------------------------------------------------
/dev/mmcblk0                                        (not mounted)
/dev/mmcblk0p1                                      /boot
/dev/mmcblk0p2                                      /
/dev/sda1                                           /media/usb0

LEideer verstehe ich davon nichts .

Ich glaube, ich erkläre einfach mal, was ich erreichen will. Möglicherweis habe ich es ja in meinem Halbwissen dumm angestellt:

1. Schreibzugriff von Windows aus über einen Samba-Share auf / und alles was darunter liegt (ich weiß, davor wird gewarnt, aber diese Diskussion lassen wir jetzt mal beiseite).
Dafür verwende ich

Code: Alles auswählen

/  /mntroot/root_fs  auto  defaults,rbind,nofail,noatime,nodiratime  0  0

Das funktioniert.

2. Die Daten der IP-Cam sollen nicht auf die SD-Karte des Raspi geschrieben werden, sondern auf einen USB-Stick, dort ins Verzeichnis "IP-Cam".
Das hatte ich gehofft, mit

Code: Alles auswählen

/media/usb /mntUSB auto  defaults,rbind,nofail,noatime,nodiratime,users,rw  0  0

zu erreichen.

Über eine Samba-Freigabe "IP-Cam" sollen die Dateien von der Webcam direkt auf den USB-Stick geschrieben werden.
Die Samba-Freigabe sieht in der smb.conf so aus:

Code: Alles auswählen

[IP-Cam]
        comment = IP-Cam
        path = /mntroot/root_fs/mntUSB/IP-Cam
        read only = No
        create mask = 0644
;        guest ok = Yes
        locking = No

Ich habe jetzt die smb.conf geändert auf

Code: Alles auswählen

        path = /mntUSB/IP-Cam

Das bringt mich zwar ans gewünschte Ziel , aber ich verstehe immer noch nicht den Unterschied zwischen "/" und "/mntroot/root_fs".

[MegaV0lt]

Habe auch nur Halbwissen, aber mit dem / Mount mit rbind wird der mount im mount nicht angezeigt. Vermutlich um eine art endloskaskade zu vermeiden. Andere Mounts sind in foot_fs/mnt aber voll vorhanden.

Am besten nur die Einhängepunkte im /mnt verwenden. Da müsste auch das Schreibrecht gehen, da ich nur Probleme mit / hatte

[TomL]

(ich weiß, davor wird gewarnt, aber diese Diskussion lassen wir jetzt mal beiseite).

Nee, lass ich nicht.... weil ich nicht die leiseste Vorstellung habe, ob Du damit Deinen Rechner nicht massiv destabilisieren kannst. Hierbei gehts mir nicht mal um die Sicherheitsaspekte, die Du mit einem Samba-Zugriff auf / von Windows geradezu fahrlässig behandelst, sondern tatsächlich um die Systemintegrität Deines Servers.

Dafür verwende ich

Code: Alles auswählen

/  /mntroot/root_fs  auto  defaults,rbind,nofail,noatime,nodiratime  0  0

Das funktioniert.
Das bringt mich zwar ans gewünschte Ziel , aber ich verstehe immer noch nicht den Unterschied zwischen "/" und "/mntroot/root_fs".

Das Root-System ist auf niedrigster Ebene betrachtet auch nur eine Verzeichnis- und Dateistruktur. Dass heisst, auf einem Speichergerät liegen (anfangs leere) Verzeichnisse und (später) Dateien. Ein Mountpoint ist anfangs also auch nur ein leeres Verzeichnis... schau einfach mal dort rein, bevor du mountest. Durch den Mount-Vorgang wird aber nicht der Inhalt des "fremden" Speichers in den Mountpoint hineinkopiert, sondern es wird nur sowas wie eine logische Verknüpfung zwischen Daten-Quelle und Mounpoint-Ziel-Verzeichnis hergestellt. Physisch bezogen auf die Daten bewegt sich bei diesem Vorgang gar nix. Das ist nur eine (logische) Verzeigerung, bei der im Mountpoint i.ü.S. sowas wie ein Zeiger auf die eigentliche Datenquelle eingerichtet wird. Das echte Verzeichnis auf dem lokalen Speicher (welches als Mountpoint eingerichtet wurde) bleibt dabei aber trotzdem weiterhin leer. Man sieht das nach dem umount.... das Verzeichnis ist immer noch da, aber wieder völlig leer. Interessant ist der Effekt, wenn im Mountpoint vor dem mount eine Datei liegt. Nach dem mount ist die "weg", nach dem umount ist sie wieder "da".

Im Endeffekt bedeutet das, wenn ich auf meiner Festplatte ein leeres Verzeichnis als Mountpoint einrichte, so bleibt das Verzeichnis selber auch dann leer, wenn ich anschliessend eine andere Datenquelle dorthin mounte. Das bedeutet, das eigentlich leere Verzeichnis bekommt nur einen Zeiger auf die zu mountende Datenquelle, die den Inhalt (oder die Leere) des Mountpoints-Verzeichnisses temporär überlagern.

Wenn du jetzt / nach /mntroot/root_fs mountest, dann wird völlig korrekt in /mntroot/root_fs ein Zeiger für / erstellt, der alle Verzeichnisse und die in den Verzeichnissen liegenden Datein zugänglich macht. Aber.... /mnt/usb ist hier KEIN in / liegender Speicherbereich, sondern nur ein Zeiger auf Verzeichnisse und Daten auf einem externen Speicher, und zwar /dev/sda1. Insofern kann in /mntroot/root_fs nur das leere Ursprungsverzeichnis /mnt/usb angezeigt werden. Warum ist das so, dass die Bilder nicht angezeigt werden? Ganz einfach, weil die temporären (!) rein virtuellen und logischen Zeiger der auf dem eigentlichen root-system gemouteten Quellen nicht auf den neuen Moutpoint mitgemountet werden. Ich kann grad gar nicht überschauen, ob das vielleicht sogar echtes Potential für zerstörerische Zirkelbezüge im Filesystem enthält. Bei mir klingeln auf Grund meiner mangelnden Fachkenntnisse auf jeden Fall alle Alarmglocken.

Ich kann Dir nur raten, den völlig unnötigen Samba-Share auf / nicht zu nutzen und sofort zu deaktivieren. Ich vermag darin auch gar keinen Sinn zu erkennen. Auf meinem Pi habe ich mir einen Admin-Share auf der Platte sda1 eingerichtet, dahin verschiebe ich die Dateien , die ich fürs System-Customizing benötige. Oder ich logge mich via SSH auf dem Pi ein und greife von dort mit MC direkt auf die Platten zu und hole mir das benötigte aus den Freigaben.... denn dort habe ich ja als "Client" meine Daten/Jobs/wassweissich zuvor gespeichert. Von Windows aus ist das mit Putty total easy zu handhaben.... ganz problemlos.

[willybauss]

So, hab's mir jetzt (mindestens) 3 mal durchgelesen und hoffe, das meiste kapiert zu haben. Erst mal besten Dank für die ausführliche Erklärung . Ich hatte die Funktion des mountens eher mir der von symbolischen Links gleich gesetzt, was offenbar nicht so ist.

Jedenfalls (so viel glaube ich verstanden zu haben) landen die Dateien tatsächlich auf dem USB-Stick und die System-SD-Karte wird nicht pausenlos gestresst. Das war letztlich der Grund für den USB-Stick.

[TomL]

...und die System-SD-Karte wird nicht pausenlos gestresst. Das war letztlich der Grund für den USB-Stick.

Dann solltest Du aber unbedingt auch noch an /var/log denken.

[willybauss]

...und die System-SD-Karte wird nicht pausenlos gestresst. Das war letztlich der Grund für den USB-Stick.

Dann solltest Du aber unbedingt auch noch an /var/log denken.

Ja, weiß ich. Dennoch besten Dank für den Hinweis. Auf dem USB-Stick ist Verkehr im Sekundentakt, weil da auch permanent Daten von der Smarthome-Steuerung eingehen. Das ist auf /var/log wesentlich entspannter.

Deshalb bin ich auch am überlegen, wie lange der Stick das mitmacht. Aber ne USB-Platte braucht mir zu viel Strom - beim 24x7 Betrieb nicht zu vernachlässigen.

[MegaV0lt]

Das ist jetzt OffTopic:

Mein Boot-Device ist eine CF-Card. Diese ist im laufenden Betrieb RO. Dafür verwende ich schon seit Jahren "Flashybrid". Mein alter SheevaPlug hatte ne SD-Card, die damit 5 Jahre durchgelaufen ist.

Außerdem habe ich noch eine kleine 40GB SSD im System, die vom Stromverbrauch auch recht sparsam sein dürfte.

Die 2TB SATA Platte ist nur für Backups meiner Geräte (PC; Laptop; VDR; Server) zuständig und geht normalerweise in den Standby

[DeletedUserReAsG]

Sticks, auf die häufig kleine Datenmengen geschrieben werden, halten in der Regel auch nicht länger, als (μ)SD-Karten. Also am besten „Drop-In-Backupstick“ bereithalten. Oder, wenn die Daten nicht soo kritisch sind, und man auch ’ne halbe Stunde oder so verlieren kann, in ein tmpfs schreiben und von Zeit zu Zeit auf den Stick sichern.

[willybauss]

Sticks, auf die häufig kleine Datenmengen geschrieben werden, halten in der Regel auch nicht länger, als (μ)SD-Karten.

Ist mir bewusst, danke. Die Technologie ist ja letztlich dieselbe. Aber so geht zumindest nicht das System über den Jordan, sondern nur ein paar Daten (die ohnehin täglich aufs NAS gesichert werden).