Hilfe: "no inodes free", kein Zugriff auf webGUI, Speicher voll nach Reboot



  • Hallo zusammen,

    ich kann mich nicht mehr mit der Oberfläche von pfSense verbinden. Über eine serielle Verbindung habe ich dann beim Bootvorgang mehrfach die Meldung no inodes free gesehen. Zudem zeigt(e) df -h an, dass der Speicherplatz zu 102% (!!) verbraucht sei.

    Schuld war u.A. ntopng.core mit 1.8GB. Diese habe ich gelöscht. Nach einem Reboot war sie allerdings wieder da.

    Eine Möglichkeit, ntopng über die Shell zu entfernen, habe ich nicht gefunden. Da beim Bootvorgang bestimmte Symlinks nicht angelegt werden können (ich kann den Output leider nicht kopieren, es ging u.A. um dhcp), funktionieren diverse Services nicht. Da nach dem Reboot die riesige ntopng Datei wieder da ist, ist wieder kein Platz für die Symlinks, da die Festplatte komplett voll ist und die Services starten wieder nicht.

    Ich habe eine APU1D als pfSense Router im Einsatz. Dort sind nur knapp 11GB Speicherplatz vorhanden, damit hatte ich allerdings noch nie Probleme.

    Könnt Ihr mir helfen, das Gerät wieder zum Laufen zu bringen? Ich hatte pfSense vor einigen Jahren mal eingerichtet, seitdem pflege ich nur noch neue Geräte ein und füge ab und zu mal Firewall Regeln hinzu, habe von der Problemlösung über shell etc. leider keine Ahnung.

    An pfSense hängt ein Unifi Switch 24 250W und daran 3 Unifi AC-AP Pro. Diese haben zumindest schon wieder Wifi aktiviert (war vorhin noch weg), aber Internet oder Netzwerk funktionieren nicht (ich kann beispielsweise keine anderen Geräte innerhalb des Netzwerks über das WLAN erreichen).

    Temporär bin ich nun über einen Ethernet Port der FB online und über serial mit pfSense verbunden.

    Vielen Dank im Voraus für Eure Hilfe :)



  • UPDATE: inzwischen kann ich über WLAN auch auf die Weboberfläche zugreifen. Wenn ich dies tue und mich anmelden will, kommt folgende Meldung

    Fatal error: Uncaught Error: Failed to create(read) session ID: files (path: ) in /etc/inc/auth.inc:1952 Stack trace: #0 /etc/inc/auth.inc(1952): session_regenerate_id() #1 /etc/inc/authgui.inc(33): session_auth() #2 /usr/local/www/guiconfig.inc(51): require_once('/etc/inc/authgu...') #3 /usr/local/www/index.php(44): require_once('/usr/local/www/...') #4 {main} thrown in /etc/inc/auth.inc on line 1952 PHP ERROR: Type: 1, File: /etc/inc/auth.inc, Line: 1952, Message: Uncaught Error: Failed to create(read) session ID: files (path: ) in /etc/inc/auth.inc:1952 Stack trace: #0 /etc/inc/auth.inc(1952): session_regenerate_id() #1 /etc/inc/authgui.inc(33): session_auth() #2 /usr/local/www/guiconfig.inc(51): require_once('/etc/inc/authgu...') #3 /usr/local/www/index.php(44): require_once('/usr/local/www/...') #4 {main} thrown
    

    Nach einem erneuten Reboot ist die Datei ntopng.core nicht mehr wieder da. df -h gibt folgendes aus

    Filesystem                     Size    Used   Avail Capacity  Mounted on
    /dev/ufsid/5b2b72eac77ee7e4     11G    8.1G    1.6G    83%    /
    devfs                          1.0K    1.0K      0B   100%    /dev
    /dev/md0                       3.4M    128K    3.0M     4%    /var/run
    devfs                          1.0K    1.0K      0B   100%    /var/dhcpd/dev
    

    df -ih

    Filesystem                     Size    Used   Avail Capacity iused ifree %iused  Mounted on
    /dev/ufsid/5b2b72eac77ee7e4     11G    8.1G    1.6G    83%    1.4M     0  100%   /
    devfs                          1.0K    1.0K      0B   100%       0     0  100%   /dev
    /dev/md0                       3.4M    128K    3.0M     4%      41   981    4%   /var/run
    devfs                          1.0K    1.0K      0B   100%       0     0  100%
    

    iused im Speicher auf 100%. Das dürfte das Problem sein. Kann ich das irgendwie beheben, ohne komplett neu zu installieren?

    Hier steht dazu folgendes

    If you get an out of inodes error, that means that:

    (a) your hdd/cf media is bad
    (b) you are the the max number of files that the slice can hold.

    Of the two, (a) is more likely, given the other errors you have, but it could go either way,

    Note that being out of inodes is not the same as being out of space. You could have too many small files (e.g. squid cache) and have lots of free space left, but no more available inodes to reference new files.

    OP dort schreibt, er probiert es mal mit einem vanilla install, danach gibt er keine Rückmeldung mehr ab. Ist allerdings auch aus dem Jahr 2010. Eine Neuinstallation würde ich gerne vermeiden. Ich recherchiere parallel weiter, wie man das Problem beheben kann, freue mich aber trotzdem über jegliches Feedback hier im Forum.



  • UPDATE 2: cd / und find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n gibt

    1 .cshrc
    1 .profile
    1 .sujournal
    1 COPYRIGHT
    1 boot.config
    1 conf.default
    4 home
    7 libexec
    9 root
    43 bin
    43 tmp
    45 cf
    67 lib
    121 sbin
    142 rescue
    225 boot
    479 etc
    17863 usr
    1421580 var
    

    usr und var kann ich ja aber schlecht einfach löschen...?

    UPDATE 3:

    ich habe touch /root/force_fsck ausgeführt und neu gestartet. Der Symlink Fehler beim startup tritt weiterhin auf. Inodes sind weiterhin zu 100% belegt. Über die webGUI kann ich mich jetzt einloggen; es ertönt der Beep der erfolgreichen Login anzeigen soll. Via serial sehe ich

    Message from syslogd@giles at Jun 22 08:52:28 ...
    giles php-fpm[328]: /index.php: Successfull login for user 'me' from: $ip (Local Database)
    

    Allerdings zeigt der Browser danach nur wieder die Login Seite an, nicht das Dashboard. Mit jedem Login Versuch kriege ich die Meldung, dass sich "erfolgreich" eingeloggt wurde, im Browser passiert aber nichts, außer, dass die Login Seite neu lädt.

    Ich habe jetzt gerade manuell fsck ausgeführt.

    fsck
    ** /dev/ufsid/5b2b72eac77ee7e4 (NO WRITE)
    
    USE JOURNAL? no
    
    ** Skipping journal, falling through to full fsck
    
    SETTING DIRTY FLAG IN READ_ONLY MODE
    
    UNEXPECTED SOFT UPDATE INCONSISTENCY
    ** Last Mounted on /
    ** Root file system
    ** Phase 1 - Check Blocks and Sizes
    INCORRECT BLOCK COUNT I=561845 (8 should be 0)
    CORRECT? no
    
    ** Phase 2 - Check Pathnames
    ** Phase 3 - Check Connectivity
    ** Phase 4 - Check Reference Counts
    UNREF FILE I=1284128  OWNER=root MODE=100666
    SIZE=0 MTIME=Jun 22 10:49 2019
    CLEAR? no
    
    ** Phase 5 - Check Cyl groups
    FREE BLK COUNT(S) WRONG IN SUPERBLK
    SALVAGE? no
    
    SUMMARY INFORMATION BAD
    SALVAGE? no
    
    BLK(S) MISSING IN BIT MAPS
    SALVAGE? no
    
    1444606 files, 2124126 used, 645994 free (346 frags, 80706 blocks, 0.0% fragmentation)
    

    Das sagt mir leider gerade alles nichts, aber vielleicht ist der Output ja hilfreich...


  • LAYER 8 Rebel Alliance

    Boote in den Single User Mode und lass so oft fsck -y / laufen bis keine Fehler mehr kommen.
    Das sauberste und wahrscheinlich auch schnellste wäre aber eine komplette Neuinstallation und dann Backup einspielen.

    -Rico



  • Vielen Dank @Rico . Das hat leider nicht funktioniert. Ich habe nun zum 3. Mal eine Neuinstallation durchgeführt, da ich vorher 2x (!!) das falsche Backup eingespielt habe und danach wieder gar nix funktioniert hat.

    Jetzt läuft alles wieder :) was kann ich tun, damit das Problem mit den inodes in Zukunft nicht mehr auftritt?

    Ich möchte zwar sowieso meine Hardware erneuern (APU1D lahmt mittlerweile ganz schön im wachsenden Netzwerk, auch wenn es nur ein privates Heimnetzwerk ist), was ja aber auch eine Kostenfrage ist. Der netgate SG-5100 wäre wohl das Minimum (wenn schon wäre ja der XG-7100 1U ein tolles neues Spielzeug xD), aber selbst ersterer ist nicht einfach so nebenbei drin.


  • LAYER 8 Rebel Alliance

    Wenn möglich ZFS benutzen, das ist robuster und geht i.d.R. nicht ganz so schnell kaputt.
    Ansonsten natürlich schauen dass dir nichts das Filesystem komplett voll schreibt, nicht einfach den Stecker ziehen, usw. Eigentlich alles was für andere Computersysteme auch gilt. ☺

    -Rico


Log in to reply