Cant login to the admin panel anymore

  • Suddenly I can't login to the admin panel anymore. My server seems to work okay, although I have been getting error messages about disk space (which is why I tried to login in the first place).

    I can login with ssh and run the omv-firstaid to change the password, but I still cant login. If I purposely do a wrong password I do get an error message, but if I do the correct password it simply returns to the login screen..

    The disk space error messages are a bit weird, since both disks attached had plenty of space the last time I Iooked. (both below 40%). The SSD (i'm running on a Raspberry that boots from SSD was never anywhere near 10%.. I do have SSD backups on harddisks as well, but I feel that would be kind of a hassle and would easily take me a whole evening to do.

    Anybody have any suggestions on how to solve this?

  • The most common reason for the exact problem you are seeing is a full system disk.


    Login via ssh and run the this command to see your disk usage.


    Code
    df -h


    If / is at 100% then look here for the solution steps:


    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Super helpful, thanks!

    Will need to dig into this later this week, but I indeed suspect rsync to a drive that for some reason didnt mount properly, filling up the SD card (running this on a raspberry with two SSDs attached). Quite annoying though, this has been working for a few months now, and I'm not backing up to remote mounts or anything so was expecting this to more stable...

  • Okay, so I took all the steps above and the problem seems to be docker logfile that had grown to 113Gb over the course of one or two weeks..


    There was indeed something weird in the contents of that logfile, which seems to have stopped now. But I'll see if I can figure out how to automatically truncate those.. Though I had the impression that stuck process might have filled up those 113Gb faster than the time between two cleanup cycles...


    Did truncate, and everything was back to normal immediately. Thanks for that link gderf !


  • Sorry, that i jumped in here. I have the same Problem.

    Code
    df -h

    shows:


    Code
    /dev/sde2

    shows 96% But when i du -xhd1 There is no Folder that is extremely big.


    What can i do? What is the Docker Overlay Folder?

  • Dont think this is the same problem... Your setup seems a bit more complicated.


    I just followed the steps as outlined in the post linked above. This meant recursively go down the folder structure one step at a time with the 'du' command, until you find the problem.

    In my case I found a Docker logfile that used about 80% of the bootdisk. This was easy to fix by just using truncate on that file.


    (further looking into the issue it turned out I had not specified the log settings in the compose.yaml file I used. So indeed, skill issue on my side. :S Hopefully it's fixed now by adding a "max size" to the logging options.. )

  • Did you go into /var/lib/docker/overlay2/[..]/merged to see if there are files there?

    Yes. For Example the first Merged Folder:

    There are no Big Files...

  • In merged:


  • Sorry.. And if you go into /dev.sde2 ?
    Also, I dont think having the disk at 96% would cause the login problem, like I had. I would think it needs 100% for that...

  • If you are running Services|Compose | Settings with its Docker storage set to the default /var/lib/docker you are setting yourself up for a recurrence of the problem. You should be using a location on a large data disk mounted in /srv, not on the system disk.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • If you are running Docker with its Docker storage set to the default /var/lib/docker you are setting yourself up for a recurrence of the problem. You should be using a location on a large data disk mounted in /srv, not on the system disk.

    The System Disk is a 500GB Disk. Is it to small? Can i easy Change the Docker Storage?

  • Sorry.. And if you go into /dev.sde2 ?
    Also, I dont think having the disk at 96% would cause the login problem, like I had. I would think it needs 100% for that...

    I also had 100%, but in the meantime i deleted the logs of the DNLA. I want to investigate the other blowed up Files...


  • The System Disk is a 500GB Disk. Is it to small? Can i easy Change the Docker Storage?

    A 500GB system disk is overly large, but it makes no difference how big or small it is if you fill it to 100%.


    Many users here can get by with a 16GB or 32GB USB or SSD disk. I run on a 32GB SSD in an external USB enclosure.


    You can move the Docker storage to another disk fairly easily. There are posts on the forum that offer guidance, so seek them out. But basically it is:


    Stop the Docker service.

    Copy all of /var/lib/docker to another drive. Be sure to retain all ownership and permissions of all the files and folders.

    Change the Docker storage folder in Services|Compose | Settings to the new location.

    Start the Docker service.

    Once you are very sure the relocation went properly you can delete the contents of /var/lib/docker.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • The strange thing is that is the first Time the Disk runs full. The Installation 2 Month old. Previously is used a USB- Stick with 128GB without any Problems with the same config. How can i Investigate which Docker Image runs the Disk full?

  • There are other possibilities that can fill the system disk.


    One is that a data disk that you write to is mounted to /srv/dev-disk-by-uuid-xxxxxxxx-yyyy-zzzz-aaaa-bbbbbbbbbbbb. But for some reason the disk didn't get mounted or became unmounted.


    All those writes will now go into the mountpoint directory but not into the disk because it is no longer attached. That mount point directory is located on the system disk, which might get filled up.


    What can make this difficult to spot is that once the disk becomes properly mounted again, you can't see the files that were written into the mountpoint directory because the contents of the attached and mounted disk overlay what you are looking for. But they are still there and they still take up space.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • Code
    root@openmediavault:~# du -sh /var/lib/docker
    18G    /var/lib/docker

    The Docker Folder is 18GB. Moving to a bigger Disk make no sense.

    If your system disk is filled up there is a reason for it. You might want to unmount your disks one at a time and examine their mount point directories. They should be empty. If not find out why.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.

    OMV AMD64 8.x on headless Tyan Thunder SX GT86C-B5630 1U Server with Intel Xeon Silver 4110 CPU @ 2.10GHz & 32GB DDR4 ECC RAM.

  • I Found it! The MiniDNLA Log Level was set to Error. I disabled it an now:


    Disk use 15G! :)

    Thanks for your help.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!