USB-Mountrechte zerstört

[Maske]

FB 7170, Freetz 1.0.1 mit syslogd, samba, wol
Am USB hängt ein Hub, ein Stick (fat) und eine größere USB-Festplatte (ext2).
Festplatte wurde an einem anderen Linux formatiert.

Wenn ich nun die Festplatte an den USB-Hub anstecke, wird die ordnungsgemäß unter uStor11 gemountet.
Wenn ich anschließend in FB Weboberfläche "USB-Speicher trennen" mache, wird die Platte entmounted. Ok. Stecke ich sie wieder rein, wieder gemounted, aber:
Jetzt keinerlei Lese/Schreibrechte des Mountpunktes /var/media/ftp/uStore11 mehr!
Ich muss nun mit meinem anderen Linux-PC diese Rechte bei der Platte erst wieder richtig einstellen, d.h. diese Rechte wurden von der FB auf der Platte direkt gelöscht.

Wenn ich jedoch den Punkt "USB-Speicher trennen" nicht mache und die Platte einfach so abstecke und dann wieder dranstecke, bleiben die Rechte ok (Schreiben+Lesen).

Kann das jemand nachvollziehen und gibts eine Lösung für das (wohl AVM-)Problem? Oder braucht man dieses "USB-Speicher trennen" gar nicht?

 

[matze1985]

hast du schon mal versucht einfach nur ein umount auf der konsole zu machen?
Was passiert dann?

 

[Maske]

hast du schon mal versucht einfach nur ein umount auf der konsole zu machen?
Was passiert dann?

Das hatte ich tatsächlich noch nicht probiert.
Also umount funktioniert in der Tat problemlos, also dann ist wohl definitiv dieses "USB Speicher trennen" irgendwie böse.

Was ich noch vergessen hatte zu sagen: bei meinem USB-Stick tritt das beschriebene Problem nicht auf, nur bei meiner USB-Festplatte.

Ich könnte mir evtl. ein Workaround Skript im autorun.sh basteln oder auf "USB Speicher sicher entfernen" verzichten und umount benutzen...

 

[olistudent]

Könnte dieser Codeschnipsel für die Rechteänderung verantwortlich sein?

...
do_umount () {
        local   DEVICE=$1
        local   MPOINT=$2
        local   MPNAME=$3
        passeeren
        [B]chmod 000 $MPOINT[/B]
        if [ -p "/var/tam/mount" ]; then
                echo "u$MPOINT" > /var/tam/mount
        fi
        if ! `umount $MPOINT > /dev/null 2>&1` ; then       # 2nd attempt
                for pid in `pidof smbd ftpd`; do
                        if `ls -l /proc/$pid/cwd /proc/$pid/fd |grep $MPOINT > /
                                kill $pid
                        fi
                done
...

Warum machen die hier einen chmod, wenn das Verzeichnis nach dem umount gelöscht wird?

MfG Oliver

 

[McNetic]

Weil sie einfach ein bisschen doo^H^H^H unkoordiniert sind. Der ganze Code ist ja irgendwie von irgendwo zusammenkopiert, was man auch schön am Sprachgemisch sieht (üblicherweise deutsch und englisch, aber dieses 'passeeren' würde ich vom Gefühl her mal als niederländisch einstufen...). In manchen Scripten (z.N. prepare_fwupgrade) wurde ja auch lange Zeit versucht, diverse Prozesse abzuschiessen, die es nie auf einer Fritzbox gegeben hat.

Ich wär dafür, das zumindest zu patchen (oder evtl. mit der neuen Hotplug-Chain komplett auszutauschen).

 

[olistudent]

Angeblich sind passeeren und vrjigiven (oder so ähnlich) gebräuchlich, wenn Locks programmiert. Aber falls dieses chmod wirklich Schuld ist, dann sollten wir das entfernen. ack

MfG Oliver

 

[cuma]

Ich würd das mal nach Mundart mit "pausieren" und "freigeben" übersetzen :-]

 

[RalfFriedl]

Warum machen die hier einen chmod, wenn das Verzeichnis nach dem umount gelöscht wird?

Da die Box normalerweise nur FAT unterstützt, wo chmod keinen Effekt hat, stört das in dem Fall nicht. Allerdings ist es auch unnötig, so daß man sich wirklich fragen muß, was die sich dabei gedacht haben.
Im Falle eines Linux-Dateisystems, wo chmod dauerhaft gespeichert ist, entfernt man damit die kompletten Zugriffsrechte auf das Hauptverzeichnis.
Immerhin gab es ja auch schon den Fall, wo alle Dateien auf dem Dateisystem gelöscht wurden, da ist das noch vergleichsweise harmlos.

dieses 'passeeren' würde ich vom Gefühl her mal als niederländisch einstufen.
In manchen Scripten (z.N. prepare_fwupgrade) wurde ja auch lange Zeit versucht, diverse Prozesse abzuschiessen, die es nie auf einer Fritzbox gegeben hat.

Die Ausdrücke passeeren und vrijgeven gehen auf den Erfinder der Semaphoren zurück, Dijkstra.

Daß alle möglichen Prozesse gestoppt werden, ob es sie in der Firmware gibt oder nicht, liegt wohl daran, daß es einfacher ist, nur eine Version der Datei zu haben, statt sie für alle möglichen Fälle anzupassen.
Wenn ein Prozeß gestoppt werden soll, der noch nie in einer Firmware existiert hat, vermute ich mal, daß es bei AVM zumindest mal Experimente damit gegeben hat, die (noch) nicht in freigegebene Firmwares eingeflossen sind.

 

[olistudent]

Ich hab jetzt ein sed eingefügt das diese Zeilen entfernt... r2451

MfG Oliver

 

[McNetic]

Die Ausdrücke passeeren und vrijgeven gehen auf den Erfinder der Semaphoren zurück, Dijkstra.

Man lernt doch immer noch dazu .

Wenn ein Prozeß gestoppt werden soll, der noch nie in einer Firmware existiert hat, vermute ich mal, daß es bei AVM zumindest mal Experimente damit gegeben hat, die (noch) nicht in freigegebene Firmwares eingeflossen sind.

Das sah für mich eher so aus, als wär das Script aus einer Firmware für ein anderes Produkt kopiert und angepasst worden. Ich hatte die Kombination der damals auffälligen Prozesse nämlich in anderem Zusammenhang auch mal gefunden. Ist aber ja letztendlich egal.

 

[hermann72pb]

Ich grabe das hier mal wieder aus. Vielleicht erinnert ihr euch noch an eure Sprachstunde in Holländisch. Meine Fragen ist:
1. Wurde das denn damals vollständig behoben?
2. Hat es denn je einer hier kapiert, was da alles beim unmount auf AVM-Art passiert?

Der Hintergrund der Frage ziehlt auf meine modifizierte mounted.cgi, mit der man nun die Devices unmounten und remounten kann. Ich hatte dort nämlich festgestellt, dass ich die FAT-Partition mit den AVM-Anrufbeantworter-Dateien drauf gar nicht auf feine Art unmounten kann. Erst, wenn ich AVM-eigene "Speicherentfernung" aus dem AVM-WebIF tätige, wird die Partition unmounted. Allerdings läuft auch dort was schief. Denn zunächst meckert AVM-WebIF, dass etwas schief gelaufen ist. Und beim nächsten Einstecken habe ich sdb anstatt sda. Ich vermute, dass AVM-Entfernungsskripte mit der SWAP-Partition (/dev/sda4) nicht klar kommen. Daher bleibt sda da irgendwie "hängen".

Wer ist hier bei uns der Semaphorenbeauftragte, der sich schon in die AVM-Denkweise reinmeditieren lies?

MfG

 

[RalfFriedl]

Das hat mit Holländisch und auch mit den Semaphoren recht wenig zu tun. Für das ursprüngliche Problem gab es einen Patch, vielleicht ist das Problem in neueren AVM-Versionen sogar nicht mehr vorhanden.

Man kann davon ausgehen, daß von AVM nur die Partitionen unmountet, von denen es weiß. Zumindest aber nur Dateisysteme und keine Swap-Partitionen. Meine Vermutung, die ich auch schon anderswo geäußert habe, ist, daß AVM den Anrufbeantworter stoppt, so daß danach keine Dateien mehr auf der Partition offen sind.

Was noch übrig ist, nachdem Du das Geräte im Web-Interface entfernen läßt, kannst Du am einfachsten selbst herausfinden.

 

[hermann72pb]

Mit dem Anrufbeantworter hatten sie sich was ganz tolles ausgedacht, nämlich ein pipe

/var/tam # ls -l
lrwxrwxrwx    1 root     root           29 Jan  1  2000 message -> /usr/share/tam/msg/default/de
[COLOR="Red"]prw-------    1 root     root            0 Jan  1  2000 mount[/COLOR]

Ich vermute, dass dieses pipe dann die Verbindung zu den AB-Dateien bildet. Die Frage ist nur, wie kann man dieses pipe verwalten. Ich bin da nicht viel schlau geworden.

Dass AVM die SWAPs nicht kennt ist schon klar, aber warum wird dann USB-Stick nach dem Wiedereinstecken als sdb und nicht als sda erkannt, obwohl mount vorher zeigt, dass alles sauber unmounted war. Dieses Verhalten kenne ich nur, wenn sda nicht "sauber" getrennt wäre. Aber welche Reste sind dann dort noch geblieben und wie kann ich sie aufspühren?

MfG

 

[RalfFriedl]

Wenn die Swap Partition noch in Verwendung ist, dann ist sda eben noch nicht ganz frei.

Zur mount-Pipe: Image mit lsof und strace, ggf. extern.

lsof /var/tam/mount

Hoffen, daß ein oder mehrere Prozesse angezeigt werden, die diese Pipe offen haben.
Strace auf diese Prozesse laufen lassen:

strace -s200 -p PID1 -p PID2 ...

Über die Web-Oberfläche unmount veranlassen. Hoffen, daß strace etwas verwertbares anzeigt.

 

[Silent-Tears]

Wenn die Swap Partition noch in Verwendung ist, dann ist sda eben noch nicht ganz frei.

Dann wäre es vielleicht sinnvoll, ein "swapoff" einzubauen beim umount? Da AVM das wohl kaum machen wird

 

[RalfFriedl]

Ein Swapoff ist nicht ein unmount, bzw. ist das Gegenstück dazu. Gibt es derzeit eine Funktion in Freetz, die gezielt alle Partitionen eines USB-Geräts freimacht?

Wenn man schon Swap einrichtet, ist es normalerweise sinnvoll, den auch zu behalten. Es sollte aus nicht Swap auf eine USB-Partition gestoppt werden, weil ein anderer USB-Datenträger entfernt wird.

 

[Silent-Tears]

Nein, so eine Funktion gibt es nicht. Aber wenn das Problem tatsächlich mit Swap zu tun hat, sollte man dort auch angreifen, oder nicht?

 

[RalfFriedl]

Es gibt doch vermutlich schon eine Möglichkeit, swap zu stoppen?

Swap und Mount hat zunächst nichts miteinander zu tun. Die einzige Verbindung wäre eine Funktion, um alle Partitionen frei zu machen, damit dann der Datenträger entfernt werden kann. Ich halte es aber für unwahrscheinlich, daß man einen Datenträger entfernen will, auf dem man Swap eingerichtet hat. Daher würde ich mit so einer Funktion warten, bis jemand Bedarf daran anmeldet.

 

[hermann72pb]

doch, doch, es wird schon vorkommen und ich denke auch relativ oft. Nicht jeder hat da 5 Festplatten an dem USB hängen. Das typische Bild bei meinen betreuten Boxen: Entweder überhaupt keinen USB-Stick und dann auch kein SWAP, oder eben nur einen USB-Stick mit einer SWAP-Partition. Und es kann schon mal vorkommen, dass jemand so ein Stick entfernen will.
Ich würde Folgendes vorschlagen:
1. Ich untersuche dieses Verhalten, ob es tatsächlich mit dem SWAP zusammen hängt. Lässt sich relativ einfach herausfinden, indem man SWAP vor dem AVM-unmount deaktiviert.
2. Ich probiere es mit swapoff, oder was da auch immer sonst dafür gibt. Evtl. sogar mit unserem SWAP-Dienst. Ziel dabei ist eine saubere Methode zu finden SWAP herunterzufahren und beim einstecken wieder zu aktivieren (wenn es den bereits nicht der Fall ist).
3. Parallel untersuche ich die Möglichkeit, wie man herausfindet, ob eine zu aktivierende/zu deaktivierende SWAP-Partition auf dem betroffenen Stick liegt. Hoffentlich reichen da die busybox-interne-Mittel.
4. Ich prüfe die Möglichkeit, ob es sinnvoll ist SWAP nicht gesondert auf der Info-Seite, sondern innerhalb von mounted.cgi unterzubringen. Ziel ist, dass dort einen "unmount"-ähnlichen Knopf kommt. Nennen wir ihn "swap off".
5. Ich wollte sowieso unter mounted.cgi eine Möglichkeit einzubauen komplette Laufwerke auf einen Klick zu unmounten. Deswegen will ich auch SWAP dazu packen. Wenn ich es auf AVM-ähnliche Weise realisieren will(/muss), würde ich dann um die AVM-Funktion mit dem Herunterfahren von AB/FAX nicht herum kommen. Der Unterschied zu AVM-Methode wäre eigentlich nur, dass man einzelne Geräte separat deaktivieren konnte (oder kann AVM das schon?) und dass man dabei auch SWAP "mitnimmt".
6. Das Mitnehmen vom SWAP in die AVM-Absteckvorbereitungsroutine würde ich ebenfalls überprüfen.

Wenn ihr konkrete Vorschläge / Ideen habt, bitte melden.

MfG

 

[RalfFriedl]

Du kennst vermutlich schon 'cat /proc/mounts'. Interessant für Dich wäre noch 'cat /proc/swaps' und das Kommando swapoff.

Wenn Swap deaktiviert wird, dann wird der gesamte Inhalt des Swaps in den Speicher geladen. Wenn der Speicher nicht reicht, wird vermutlich entweder die Box neu starten oder swapoff nicht erfolgreich sein.

Wenn ein gesamter Datenträger deaktiviert wird, dann ist swapoff in diesem Zusammenhang mit umount schon sinnvoll. Auch unter dem Gesichtspunkt 'Datenträger nach Partitionen anzeigen' würde es passen.