Login am GUI nicht möglich

    • OMV 2.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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
      OMV stoneburner | HP Microserver | 256GB Samsung 830 SSD for system | 4x 2TB in a RAID5
      OMV erasmus| Odroid XU4 | 5TB Data drive | 500GB Backup drive

      The post was edited 1 time, last by WastlJ ().

    • WastlJ wrote:

      omavoss wrote:

      Das kann es doch nicht sein!! Hier sollten die Entwickler mall einen gewaltigen Scheit auflegen, BEVOR sie sich auf 3.0.x stürzen.

      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
    • erik wrote:

      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. ;)
      OMV stoneburner | HP Microserver | 256GB Samsung 830 SSD for system | 4x 2TB in a RAID5
      OMV erasmus| Odroid XU4 | 5TB Data drive | 500GB Backup drive
    • @WastlJ

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

      Source Code

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


      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!
      Files
      • disk-usage.txt

        (43.26 kB, downloaded 138 times, last: )

      The post was edited 2 times, last by omavoss ().

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

      Source Code

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

      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?

      Source Code

      1. ls -la /media


      und

      Source Code

      1. 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.
    • @Zoki

      Source Code

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


      und

      Source Code

      1. root@FSC:~# ls -la /media/f90c135b-1b99-4dbc-9260-28a13561d27c
      2. insgesamt 12
      3. drwxr-xr-x 3 root root 4096 Mär 27 03:30 .
      4. drwxr-xr-x 6 root root 4096 Mär 27 03:30 ..
      5. drwxr-xr-x 3 root root 4096 Mär 27 03:30 Bilder-usb
      6. 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.
    • Hallo,

      zwei Gläser Wein weiter wage ich mal eine Diagnose:
      1. 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.
      2. Die USB-Platte wurde entfernt, ohne den Share zu löschen und das Dateisystem ordentlich aus OMV auszuhängen (evtl. wurde wischenezitlich mal rebootet)
      3. Es ist keine Benachrichtigungsadresse eingegeben, an die das NAS Fehlermeldungen schicken kann (Platte fehlt bzw. root Filesystem voll)
      4. 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:
      1. 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
      2. über die Web-Oberfläche ein neues Share SHARE anlegen für das Verzeichnis /dev/sdb1/Bilder-usb anlegen
      3. testen, das alles da ist, wo es sein soll
      4. die USB-Platte wieder anschließen und ordentlich in OMV einbinden
      5. und die ganze Operation wieder rückwärts mv /media/ff37ba74-4584-4f74-9dab-265197e72994/Bilder-usb /media/f90c135b-1b99-4dbc-9260-28a13561d27c
      6. das neu angelegte Share SHARE wieder löschen
      7. ein neues Share auf der USB-Platte für das Verzeichnis Bilder-usb auf der USB-Platte anlegen.
      8. 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.

      The post was edited 1 time, last by Zoki ().

    • @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.
    • 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

      The post was edited 1 time, last by Zoki ().

    • 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.
    • @Zoki,
      neue niederschmetternde Nachrichten:
      putty wirft aus:

      Source Code

      1. root@FSC:~# mv /media/f90c135b-1b99-4dbc-9260-28a13561d27c/* /media/ff37ba74-4584-4f74-9dab-265197e72994
      2. 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
      3. root@FSC:~#
    • 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.
    • @Zoki

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

      Source Code

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


      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.