OMV 7 : I have a problem with accessing OMV via the web interface.

1st Official Post

    Hello!


    When I access OMV with a file manager I get everything displayed, when I try to log in via the web interface or via SSH it is denied.


    How can I access the interface?


    Many thanks in advance.


    Yours sincerely, R.Lehmeier

  • Lehmeier

    Changed the title of the thread from “I have a problem with accessing OMV via the web interface.” to “OMV 7 : I have a problem with accessing OMV via the web interface.”.

    You don't say what user:password you are using when logging in for both cases.

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


    In the default install, the admin user can not login via ssh, only via the WebUI.


    To access via ssh, the user must belong to the _ssh group and have a specified shell.


    You might want to show exactly how you are logging in - post screenshots or text from terminal.

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


    Ok, I found the error - it was sitting in front of the monitor.

    I had always tried to log in with the password from OMV via SSH, but I needed the password from my desktop computer with which I wanted to log in.



    Unfortunately, I still don't know how to access the GUI or how to change the password for OMV.

    Is it enough if I change the password for the Debian or do I have to do this separately for the GUI? Not really - right.

    Once you ssh in as a user you can run omv-firstaid as root or using sudo. From there you can change the WebUI admin user's password, reset the failed login lockout counter and more.


    Another possibility for endless loop WebUi login failures is a full root filesystem. Run df-h to check for that.

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


    df -h

    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf

    udev 3,7G 0 3,7G 0% /dev

    tmpfs 754M 2,9M 751M 1% /run

    /dev/sda2 218G 207G 0 100% /

    tmpfs 3,7G 84K 3,7G 1% /dev/shm

    tmpfs 5,0M 0 5,0M 0% /run/lock

    /dev/sda1 511M 148K 511M 1% /boot/efi

    tmpfs 3,7G 0 3,7G 0% /tmp

    /dev/sdg1 3,6T 765G 2,7T 22% /srv/dev-disk-by-uuid-062066f3-0165-4cf2-a186-87640e077e40

    /dev/sdc1 7,3T 3,8T 3,2T 55% /srv/dev-disk-by-uuid-03bdce30-3962-43f8-86b0-d96be773a97e

    /dev/sdf1 7,3T 4,5T 2,5T 65% /srv/dev-disk-by-uuid-46f3ca15-f4c0-47be-9793-fcc64875c043

    /dev/sde1 7,3T 3,1T 3,9T 45% /srv/dev-disk-by-uuid-e7cdaf24-19b8-4486-978d-8cc590019ae5

    /dev/sdb1 3,6T 2,7T 782G 78% /srv/dev-disk-by-uuid-74c13dfc-151f-4d4a-b9d4-df481f6a55a4

    /dev/sdd1 3,6T 2,6T 867G 76% /srv/dev-disk-by-uuid-b428da2f-5c1d-422c-8ae2-56df39889290




    It looks like /dev/sda2/ is full but with what and how do I get it empty or pushed down again?

    Yes, your rootfs is full. See here for how to fix it:


    Thread
    [How-To] Fix full OS filesystem - GUI login loop
    Symptoms

    When you try to login to the GUI of OMV you are not being logged in, but the login page shows up again

    Check, if a full root filesystem is the problem
    ssh into your server (check the new user guide on how to ssh into your server) and run following command
    df df will show you the usage of each filesystem
    the output of df will look like this:
    (Code, 19 lines)

    The filesystem dev/sda1 which is mounted on "/" is the OS filesystem. The use of that filesystem is 100% --> the OS filesystem is full.

    …
    macom

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


    I was able to determine that /var is the largest directory and with ls -al I got this.

    Unfortunately it doesn't tell me why /var is so big.


    Run this command. If you don't have the ncdu program, install it.


    Code
    ncdu /var

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


    Unfortunately, it doesn't work because I supposedly don't have enough space.




    When I try to go to the directory I get the following :


    Code
    $ cd /var/cache/apt/archives/
$ dir
lock  partial
    • Official Post

    sudo apt-get clean

    sudo du -d1 -h -x /var | sort -h

    omv 7.7.3-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0.2 | kvm 7.1.2 | compose 7.4.4 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.1


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!


    I don't understand how the few files can take up over 200 Gb.

    What is the best way to delete them and how can I prevent it from filling up again?

    • Official Post

    You can delete all the *.gz files. Those are older compressed logs. Looks like you will still have enough logs for investigation.


    Quote from Lehmeier

    how can I prevent it from filling up again?

    Have a look at the logs and see what messages / errors are logged. That should give you a hint, what is going on.


    Post this as ryecoaaron suggested

    sudo du -d1 -h -x /var | sort -h

    Ok, but I don't know what to check.

    Wouldn't it be easier to delete everything, or just the numbered files? They will be recreated anyway.

    If I only delete the numbered files then the current logs are still there.

    Or am I wrong.

    • Official Post

    The logs are so large for a reason. If you don't find the reason and fix it, it will happen again. Deleting the logs is only a temporary fix.


    If you just run journalctl -e you can scroll through the log. Most likely you will find a few lines that are repeating over and over again. Post them here and someone might have an idea how to dig deeper.

    • New

    Since I couldn't find anything that seemed strange to me, I deleted everything except the readme and installer.


    Now it looks like this :


    and


    Code
    sudo du -d1 -h -x /var/log/ | sort -h       
14M     /var/log/
14M     /var/log/installer


    Is there a possibility in Openmediavault to set what exactly should be saved in the logs and when they can be deleted automatically? So that the system no longer runs so full.

    • New
    Quote from Lehmeier

    Is there a possibility in Openmediavault to set what exactly should be saved in the logs and when they can be deleted automatically? So that the system no longer runs so full.


    I run logrotate but I do not remember if it is a core OMV program or I installed it myself.


    You may as well install ncdu now and give it a try.

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


Participate now!

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

Register Yourself Login