Shares ok, no SSH, no access to web GUI

  • Hi


    Haven't logged-in on web gui for a few days and now I cannot reach OMV on raspberry-pi 4, no SSH, no web GUI, both give a time-out.
    I can read and write the USB HDD share.
    Guess only option is hard reset, how do I best do it, unplug power to HDD first or just unplug rpi, or unplug usb first?
    Or is there an other option?


    Thanks Dirk

  • Could it be that this happened because of an automatic update (if this exists) ore something similar?
    In that case I could wait until a next one witch hopefully fix it.

    • Offizieller Beitrag

    No, I doubt that.


    It is more likely that you are using the wrong IP or the root filesystem is full. Or you need to clear the web browser cache.


    After you have shutdown you may want to examine the contents of the root fs to see if the root fs is full. Or something else wrong.

  • So did a clean install, did an overwrite format, checked the sd-card, new install.
    Only activated afp and shairport.
    Worked perfect for 11 days, then total crash.
    Got a copy of the sd card, where should I look for causes?

    • Offizieller Beitrag

    Total crash, what does that mean? Black smoke from the RPi4 and unable to reboot?


    Check how much free storage there is left on the root fs. Is it full? It is the 7-8 GB partition you should examine.


    Then:


    Look for folders with a lot of files/data in them. Especially in places where devices/network shares often are mounted. Look under /srv, /media, /mnt. Look everywhere.


    It is possible that a mount for a HDD or for a remote share stopped working. Perhaps because the device wasn't availible (fast enough) during boot. Or was turned off and then not remounted from the RPi4. Then any file transfer to that device may go straight into the mount point folder, quickly filling the root fs.


    This is a common problem with USB connected HDDs. USB is not very reliable. And if you bump a cable the device may be unmounted by mistake.


    I use autofs so that all my network mounts are automatically remounted if the go down.

  • Thanks Adoby for your time,


    Used 1.7GB, free 6.17GB


    So if I understand correct; root fs is not full and so there's no need to investigate further on this disc, right?


    Installation has a pretty stable setup, no moving cables, over dimensioned solar power setup, (no chance of power failure on the hdd or the raspberry-pi)
    All the time the system was up, no inbetween boots.


    Have a program on a server, SecuritySpy, witch is making new maps for cameras each day as soon as there's an activation through the camera itself, so not all the cameras (for now just 4) trying to write a new map at the same time.


    Any suggestions to figure out what's happening?


    Will check out this autofs...


    Cheers, Dirk

    • Offizieller Beitrag

    Total crash, what does that mean? Black smoke from the RPi4 and unable to reboot?


    No, the rootfs is not full.


    The common method to figuring out why a Linx server is crashing is to examine the log files after a crash. Often errors are reported in them before the system crash. Or you may just see something starting up, just before the crash. And that directly or indirectly might tell you what the problem is.


    Yet another to avoid installing 3:rd party stuff. Some software is unstable, bad or faulty and cause problems.


    Still another way is to monitor stuff like memory usage, disk/network I/O, power and temperatures. The RPi4 is sensitive to overheating and under voltage. Do some stress testing. Max processing and run all peripherals at full utilization at once. Do the RPi4 throttle due to overheating? Does it crash due to under voltage?

  • Total crash, I ment not responding system, not able to ssh, no communication possible, no shares, no shairport, no gui, no response whatsoever and not rebooting on power off and on.
    (no black or white smoke though :) and in the meanwhile rpi with omv up and running again)


    So the system was up from 11 till 23 of oktober,
    I have a syslog only of Okt 14
    I have a syslog.1only Okt 13 and 14
    I have a userlog only of Okt 13 and 14
    I have a userlog.1 only of may 31, okt 11 and 12
    I have a auth.log of okt 13 and 14
    I have a auth.log.1 of okt 12
    I have a deamon.log of okt 13 and 14
    I have a deamon.log.1 of okt 12 and 13
    faillog is empty
    kernlog of okt 14
    kernlog.1 may31, okt 11 and 12
    lastlog empty
    initsystemlog empty


    cannot find anyting after 15 of okt


    not very usefull is it?


    Cheers Dirk

    • Offizieller Beitrag

    No, not very useful.


    But not being able to reboot after power off/on is very strange and intersting. And might be revealing. There must be persistent changes to the filesystem that cause it to not boot any more.


    A full rootfs should be a obvious suspicion, but that is already ruled out. So how else do the filesystem differ from a working filesystem?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!