Login am GUI nicht möglich

WastlJ · 13. April 2016

Bitte den vollständigen Code ausführen, der / ist wichtig.
ls -hal /

Bezüglich des "Fehlers" von Zokis Code, das passt so. Hier fehlt nur noch ein
cat /tmp/disk-usage.txt

Zoki · 13. April 2016

Die Datei müsste trotzdem da sein.

Ach so: Häng die doch bitte hier an.
Falls Du per OMV darauf zugreifen möchtest:

Code

cp /tmp/disk-usage.txt /media/ff37ba74-4584-4f74-9dab-265197e72994/Downloads

und dann über dem Share Downloads darauf zugreifen.

erik · 13. April 2016

Zitat von WastlJ

Mal ruhig oma. Für ein vollgelaufenes rootfs war noch -nie- ein Entwickler schuld. Das ist entweder owncloud, ein eigens verkonfigurierter rsync oder überlaufende LOG Dateien.

naja, so ganz falsch liegt omavoss nicht.

Mit "Schuld" hat das natürlich nichts zu tun, der Entwickler stellt kostenfrei ein NAS-Paket zur Verfügung, und wer es einsetzt weiß was er macht. Ich nutze es auch seit 4 Monaten und bin sehr zufrieden.

Allerdings hat OMV etliche Ecken und Kanten, die dem selbstgesteckten Ziel: "for home users" oder "simple and intuitive" nicht völlig gerecht werden. Wenn nginx einen Mindestspeicherbereich für den elementaren Webzugang braucht, dann müsste der auch irgendwie geschützt sein - gegen owncloud oder was auch immer (nur ein Beispiel). Ich hab das bei mir mit USB-Stick und SSD gelöst (Datenplatten kommen extra) und auf dem USB-Stick liegt das system und sonst nichts, auch kein selbst eingerichteter Share. Aber simple ist das nicht.

Das ganze ist natürlich ein Zielkonflikt. Sollen die begrenzten Entwicklerresourcen (zu denen ich leider auch nichts beitragen kann) in die Weiterentwicklung gesteckt werden, um auf Höhe der Softwaremöglichkeiten zu bleiben, oder steckt man Arbeit in die Verbesserung der Usability um Beginnern über die Brücke zu helfen?

Ein Weg könnte es sein, die Nutzer ohne Unix-Engineer-Background in die Verbesserung der Usablity einzubinden, und wenn sie nur Dokus oder Wikis erstellen.

Ein richtiges "Pfund" ist natürlich das Forum, dessen Support in der Qualität und Reaktionsschnelligkeit auch so manches kommerzielles Produkt weit hinter sich läßt.
Daher von mir ein ausdrückliches Danke an den Entwickler von OMV und an tekkb und ryecoaaron, deren Geduld ich echt bewundere.
Erik

WastlJ · 13. April 2016

Zitat von erik

gegen owncloud oder was auch immer

Wie mans nimmt - Nutzt man ausschließlich die Plugins, die in der Pluginliste auftauchen, kommen diese Probleme -niemals- zustande. Auch nicht mit dem Owncloud Plugin. Wovon ich rede, sind eigene Installationen via Commandline. Und davon kann sich OMV nunmal nicht schützen.

Aber lass uns erstmal warten, was oma für Infos mit den Commands postet. Danach sollte sich ja relativ bald das Geheimnis lüften, was die Festplatte so zugemüllt hat.

omavoss · 13. April 2016

@WastlJ

Ich habe inzwischen etwas die Übersicht verloren,
hier der Output auf die commands:

Code

root@FSC:~# ls -hal /
insgesamt 104K
drwxrwxrwx   3 root root  4,0K Feb 11 21:50 ~
drwxr-xr-x  26 root root  4,0K Apr 13 07:50 .
drwxr-xr-x  26 root root  4,0K Apr 13 07:50 ..
drwxr-xr-x   2 root root  4,0K Feb 21 18:23 bin
drwxr-xr-x   3 root root  4,0K Apr  5 22:19 boot
drwxr-xr-x  16 root root  3,3K Apr 12 21:23 dev
drwxrwxr-x 112 root root   12K Apr 13 17:40 etc
drwxr-xr-x   4 root root  4,0K Mär 21 16:40 export
drwxr-xr-x   7 root root  4,0K Mär 24 11:18 home
drwxr-xr-x  14 root root  4,0K Feb 11 18:29 lib
drwxr-xr-x   2 root root  4,0K Feb 17 10:13 lib64
-rw-r-----   1 root root     0 Mär 17 23:46 lock
drwx------   2 root root   16K Feb 11 16:20 lost+found
drwxr-xr-x   6 root root  4,0K Mär 27 03:30 media
drwxr-xr-x   2 root root  4,0K Dez 24  2014 mnt
drwxrwxr-x   6 root users 4,0K Feb 12 17:50 opt
drwxr-xr-x   2 root root  4,0K Apr  5 22:18 partial
dr-xr-xr-x 145 root root     0 Apr 12 21:22 proc
drwx------   6 root root  4,0K Mär 18 23:31 root
drwxr-xr-x  23 root root  1,2K Apr 13 14:29 run
drwxr-xr-x   2 root root  4,0K Apr  3 18:12 sbin
drwxr-xr-x   2 root root  4,0K Jun 10  2012 selinux
drwxr-xr-x   4 root root  4,0K Feb 11 16:20 srv
dr-xr-xr-x  13 root root     0 Apr 12 21:22 sys
drwxrwxrwt   7 root root   180 Apr 13 17:45 tmp
drwxr-xr-x  10 root root  4,0K Feb 11 16:20 usr
drwxr-xr-x  14 root root  4,0K Mär 17 16:15 var
root@FSC:~#

Alles anzeigen

und die disk-usage.txt im Anhang.

Die Nuss muss doch zu knacken sein!

bitte: es handelt sich NICHT um die Maschine, die in der Signatur dargestellt ist! Hier ist OMV auf FSC mit einer System-Disk und einer Daten-Disk sowie einer USB-Disk, mehr nicht!

Zoki · 13. April 2016

Als erstes fällt auf, dass unter /home/jdownloader/Downloads 3,4 GB gespeichert sind, hier was zu löschen könnte schon mal Platz schaffen. Für den Rest muss ich mir die Datei nochmal genauer ansehen.

Zoki · 13. April 2016

Bist Du sicher, dass das der gleiche Rechner ist, wie der, von dem Du das hier

Code

root@FSC:~# df -h
Dateisystem                                            Größe Benutzt Verf. Verw% Eingehängt auf
rootfs                                                   71G     71G     0  100% /
udev                                                     10M       0   10M    0% /dev
tmpfs                                                   771M    1,7M  770M    1% /run
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /
tmpfs                                                   5,0M       0  5,0M    0% /run/lock
tmpfs                                                   1,6G    4,0K  1,6G    1% /run/shm
/dev/sdb1                                               2,7T    1,5T  1,2T   56% /media/ff37ba74-4584-4f74-9dab-265197e72994
/dev/sdb1                                               2,7T    1,5T  1,2T   56% /export/PXE
/dev/sdb1                                               2,7T    1,5T  1,2T   56% /export/Musik
tmpfs                                                   1,6G    2,5M  1,6G    1% /tmp
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/log
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/lib/rrdcached
folder2ram                                              3,8G     42M  3,8G    2% /var/log
folder2ram                                              3,8G     16M  3,8G    1% /var/lib/rrdcached
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/spool
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/lib/php5
folder2ram                                              3,8G     32K  3,8G    1% /var/spool
folder2ram                                              3,8G       0  3,8G    0% /var/lib/php5
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/lib/monit
folder2ram                                              3,8G    8,0K  3,8G    1% /var/lib/monit
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/lib/openmediavault/rrd
folder2ram                                              3,8G    644K  3,8G    1% /var/lib/openmediavault/rrd
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G     71G     0  100% /var/folder2ram/var/tmp
folder2ram                                              3,8G       0  3,8G    0% /var/tmp

Alles anzeigen

geholt hast?

Ich sehe hier ein Verzeichnis mit 64G /media/f90c135b-1b99-4dbc-9260-28a13561d27c/Bilder-usb, aber es ist nirgendwo ein eigenes Laufwerk dafür eingebunden. Ist das ein Verzeichnis auf /root oder eine eingebundene Festplatte, die vorher nicht dargestellt ist?

Code

ls -la /media

und

Code

ls -la /media/f90c135b-1b99-4dbc-9260-28a13561d27c

Das ist die einzige Stelle, wo für mich Unstimmigkeiten liegen, außer, dass auf dem Rechner für ein NAS relativ viel installiert ist.

omavoss · 13. April 2016

@Zoki

Code

root@FSC:~# ls -la /media
insgesamt 24
drwxr-xr-x  6 root root 4096 Mär 27 03:30 .
drwxr-xr-x 26 root root 4096 Apr 13 07:50 ..
lrwxrwxrwx  1 root root    6 Feb 11 16:20 cdrom -> cdrom0
drwxr-xr-x  2 root root 4096 Feb 11 16:20 cdrom0
drwxr-xr-x  3 root root 4096 Mär 27 03:30 f90c135b-1b99-4dbc-9260-28a13561d27c
drwxr-xr-x 15 root root 4096 Apr  1 18:10 ff37ba74-4584-4f74-9dab-265197e72994
lrwxrwxrwx  1 root root    4 Feb 11 16:20 usb -> usb0
drwxr-xr-x  2 root root 4096 Feb 11 16:20 usb0
root@FSC:~#

Alles anzeigen

und

Code

root@FSC:~# ls -la /media/f90c135b-1b99-4dbc-9260-28a13561d27c
insgesamt 12
drwxr-xr-x 3 root root 4096 Mär 27 03:30 .
drwxr-xr-x 6 root root 4096 Mär 27 03:30 ..
drwxr-xr-x 3 root root 4096 Mär 27 03:30 Bilder-usb
root@FSC:~#

tut mir echt leid, aber ich bin bei weitem kein Profi, auch wenn das unter meinem Avatar steht. Danke für den Hinweis, dass auf ein NAS nicht soviel Kram draufgehört, ich werde das zukünftig beherzigen. Ich dachte eben nur, testen könnte nicht schaden.

Trotzdem nochmal: warum lässt es ein Plugin (hier jDownloader) überhaupt zu, dass ein Share im root erstellt werden kann? Damit es zu derlei Problemen wie hier bei mir passiert kommen kann? Ich glaube es nicht, ich selbst habe hier irgendwas falsch gemacht.

Ich habe jetzt alle Downloads unter jdownloader gelöscht, immer noch negativ, kein Login möglich.

Viele Grüße.

erik · 13. April 2016

Zitat von omavoss

Ich habe jetzt alle Downloads unter jdownloader gelöscht, immer noch negativ, kein Login möglich.

Viele Grüße.

Wie sieht

df -h

jetzt aus?

Zoki · 13. April 2016

Hallo,

zwei Gläser Wein weiter wage ich mal eine Diagnose:

Es gab mal eine USB-Festplatte, die an das NAS angeschlossen war. Dort wurde ein Share Bilder-usb angelegt und freigegeben oder in einem Plugin verwendet.
Die USB-Platte wurde entfernt, ohne den Share zu löschen und das Dateisystem ordentlich aus OMV auszuhängen (evtl. wurde wischenezitlich mal rebootet)
Es ist keine Benachrichtigungsadresse eingegeben, an die das NAS Fehlermeldungen schicken kann (Platte fehlt bzw. root Filesystem voll)
Das Share wurde weiter genutzt und randvoll gefüllt. Doch weil da keine USB-Festplatte mehr ist, wurde das root Filesystem randvoll gefüllt.

Als Erklärung: Wenn unter Unix ein Dateisystem eingebunden werden soll, legt man einen "mount point" an. Das ist ein einfaches Verzeichnis, an dessen Stelle dann die Platte (oder eine deren Partitionen) eingehängt wird. Wird die Platte wieder entfernt, bleibt der mount point als einfaches Verzeichnis stehen. Darin kann man natürlich auch Dateien ablegen, aber die liegen dann halt auf einer anderen Platte als beabsichtigt.

Falls das so ist, kannst Du mir ein Bier ausgeben und zm Beheben des Problems:

von der Konsole den Inhalt von /media/f90c135b-1b99-4dbc-9260-28a13561d27c nach /media/ff37ba74-4584-4f74-9dab-265197e72994 verschieben
mv /media/f90c135b-1b99-4dbc-9260-28a13561d27c/* /media/ff37ba74-4584-4f74-9dab-265197e72994
über die Web-Oberfläche ein neues Share SHARE anlegen für das Verzeichnis /dev/sdb1/Bilder-usb anlegen
testen, das alles da ist, wo es sein soll
die USB-Platte wieder anschließen und ordentlich in OMV einbinden
und die ganze Operation wieder rückwärts mv /media/ff37ba74-4584-4f74-9dab-265197e72994/Bilder-usb /media/f90c135b-1b99-4dbc-9260-28a13561d27c
das neu angelegte Share SHARE wieder löschen
ein neues Share auf der USB-Platte für das Verzeichnis Bilder-usb auf der USB-Platte anlegen.
eine Benachrichtigungsadresse für Fehlermeldungen in OMV eintragen.

Und wenn das nicht funktioniert hätte ich gerne die Ausgabe von tail -200 /var/log/nginx/openmediavault-webgui_error.log und wen die leer ist tail -200 /var/log/nginx/openmediavault-webgui_error.log. Das sollte doch in den Griff zu kriegen sein.

omavoss · 13. April 2016

@Zoki sieht alles ganz plausibel aus.Deine Annahmen sind alle? richtig.

1. stimmt, USB-Platte war angeschlossen und ein share Usb-Bilder eingerichtet
2. die Usb-Platte wurde einfach abgezogen und nicht ausgehängt
3. es wurde keine Benachrichtigungsadresse eingegeben (ich sah bisher keine Veranlassung dafür)
4. kann ich nicht so recht nachvollziehen, aber des wird wohl so stimmen.

Ich will nun die von Dir gegebenen Hinweise korrekt ausführen und bitte um etwas Geduld. Online ein oder mehrere Bier(e) ausgeben ist problematisch ... ich würde das aber sehr gern tun.

Sobald ich über das GUI wieder zugreifen kann werde ich neue Shares anlegen usw. usw.

Ich melde mich, falls es weiterhin Probleme geben sollte, einstweilen vielen Dank.

Freundliche Grüße.

Zoki · 13. April 2016

Du kannst die Schritte mit dem Share anlegen auch auslassen, wenn Du über die Konsole prüfen kannst, dass die Daten dort angekommen sind, wo sie sollten.
... und wenn Du keinen Wert auf die Daten legst, ist das in wenigen Sekunden erledigt:
rm -rf /media/f90c135b-1b99-4dbc-9260-28a13561d27c/Bilder-usb
Update: Pfad gändert

omavoss · 13. April 2016

@Zoki
der Vorgang "mv /media/f90c135b-1b99-4dbc-9260-28a13561d27c/* /media/ff37ba74-4584-4f74-9dab-265197e72994" läuft noch; am liebsten wäre es mir, wenn ich die USB-Platte ganz außen vor lassen könnte. Irgendwie "unmounten", und die UUID von der USB-Platte nie wieder sehen im OMV!

Zoki · 13. April 2016

Das sollte eigentlich kein Problem sein, wenn Du dich wieder anmelden kannst.
Schau einfach mal, was dann an Dateisystemen angezeigt wird. Einfach das Share entfernen und dann das Dateisystem aushängen (dazu muss aber die Platte mit der UUID f90c135b-1b99-4dbc-9260-28a13561d27c angesteckt sein) ansonsten hilft nur ein Eingriff mit dem Editor.

Sag einfach Bescheid, wenn alles verschoben ist, ichbin noch ca. 1 h da.

omavoss · 13. April 2016

@Zoki,
nur kurz nebenher:
die USB-Platte ist nicht angesteckt, trotzdem rödeln auf der OMV-Maschine die Festplatten unentwegt und sind offenbar mit dem "mv"-Vorgang beschäftigt.

Ist das ein gutes Zeichen?

omavoss · 13. April 2016

@Zoki,
neue niederschmetternde Nachrichten:
putty wirft aus:

Code

root@FSC:~# mv /media/f90c135b-1b99-4dbc-9260-28a13561d27c/* /media/ff37ba74-4584-4f74-9dab-265197e72994
mv: Verschieben zwischen Geräten fehlgeschlagen: „/media/f90c135b-1b99-4dbc-9260-28a13561d27c/Bilder-usb“ zu „/media/ff37ba74-4584-4f74-9dab-265197e72994/Bilder-usb“; kann Ziel nicht entfernen: Ist ein Verzeichnis
root@FSC:~#

Wolf2000 · 13. April 2016

Mit
mv -r

omavoss · 13. April 2016

root@FSC:~# mv -r /media/f90c135b-1b99-4dbc-9260-28a13561d27c/* /media/ff37ba74-4584-4f74-9dab-265197e72994
mv: ungültige Option -- „r“
„mv --help“ gibt weitere Informationen.
root@FSC:~#

Zoki · 13. April 2016

Achtung -r heißt force, nur ausführen, wenn klar ist, woran es liegt.

was sagt denn wc | ls -1 /media/ff37ba74-4584-4f74-9dab-265197e72994/Bilder-usb und was
wc | ls -1 /media/f90c135b-1b99-4dbc-9260-28a13561d27c/Bilder-usb

Ist der Rechner von außen ereichbar, dann kann ich mal schauen, was ich machen kann.

Ansonsten: Ziel des mv Befehls ist es, den Inhalt von /media/f90c135b-1b99-4dbc-9260-28a13561d27c/ nach /media/ff37ba74-4584-4f74-9dab-265197e72994/ zu verschieben.
Wenn das nicht geht, könnte man noch mit rsync -av /media/f90c135b-1b99-4dbc-9260-28a13561d27c/Bilder-usb /media/ff37ba74-4584-4f74-9dab-265197e72994/Bilder-usb kopieren und dann mit rm -rf /media/f90c135b-1b99-4dbc-9260-28a13561d27c/Bilder-usb die Quelle löschen.

omavoss · 15. April 2016

@Zoki

Ich habe alles so ausgeführt wie du oben beschrieben hsat, einschließslich die Quelle gelöscht.
putty wirft aus:

Code

root@FSC:~# df -h
Dateisystem                                            Größe Benutzt Verf. Verw% Eingehängt auf
rootfs                                                   71G    3,9G   63G    6% /
udev                                                     10M       0   10M    0% /dev
tmpfs                                                   771M    1,3M  770M    1% /run
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /
tmpfs                                                   5,0M       0  5,0M    0% /run/lock
tmpfs                                                   1,6G    4,0K  1,6G    1% /run/shm
/dev/sdb1                                               2,7T    1,6T  1,2T   58% /media/ff37ba74-4584-4f74-9dab-265197e72994
/dev/sdb1                                               2,7T    1,6T  1,2T   58% /export/PXE
/dev/sdb1                                               2,7T    1,6T  1,2T   58% /export/Musik
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/log
folder2ram                                              3,8G     67M  3,7G    2% /var/log
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/spool
folder2ram                                              3,8G    280K  3,8G    1% /var/spool
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/lib/monit
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/lib/php5
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/lib/rrdcached
folder2ram                                              3,8G       0  3,8G    0% /var/lib/php5
folder2ram                                              3,8G    8,0K  3,8G    1% /var/lib/monit
folder2ram                                              3,8G     14M  3,8G    1% /var/lib/rrdcached
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/lib/openmediavault/rrd
folder2ram                                              3,8G    788K  3,8G    1% /var/lib/openmediavault/rrd
/dev/disk/by-uuid/3d76df1d-f984-4bc0-8134-51b2b362c1b8   71G    3,9G   63G    6% /var/folder2ram/var/tmp
folder2ram                                              3,8G       0  3,8G    0% /var/tmp
root@FSC:~#

Alles anzeigen

trotzdem immer noch unverändert kein login möglich, auch nach "shutdown -r now" nicht.
Ich bin immer noch auf der Suche nach der Ursache und bitte weiterhin um Unterstützung.

Viele Grüße.

Jetzt mitmachen!