Posts by Huberer


    Thanks. I know that OMV is not an OS. OMV is just a GUI for Debian Server. This is what I learned for sure in the last years :)
    I've installed virtualbox via CLI and it was very easy to install. I saw that Virtualbox is not in the Debian repos and I also read why. But with adding the repos it was very easy. I also found that someone is supporting an unofficial repo for Virtualbox for Debian 10.
    I also could install the extension pack but, than came phpvirtualbox. That was really terrible but at the end and with a lot of testing I also could get phpvirtualbox to run. But the autostart of the VM's was the real pain therefore I stopped everything and deleted virtualbox.
    Maybe I will look at KVM and see how this works.

    Thanks anyway for the info.

    Now I found out that there's a phpvirtualbox image on docker. Maybe I will test this to see if it's possible to run VM's under OMV/Debian.


    is there a chance to get Virtualbox working under OMV v5?
    It looks like that this is the first "Server OS" without the possibility to run virtual machines besides OMV (except by using ESXI - which I really don't know how it works). OMV v4 with the Virtualbox Plugin was great. I really loved it.
    Maybe there's a chance to get Virtualbox running under OMV v5.

    Thanks in advance

    Which version of Debian 9 did you use for installation. I did it several times and didn't face any problems.

    I used this version for basis installation. At the end when you have to choose which packages to install I only ticked "ssh server" and "standard system utilities". You don't need more. Don't install a GUI like Xfce ....

    After the the first login with root (I install the server with a keyboard/mouse and screen attached) I enabled root. After that I reboot the server again.

    And then I connected from another PC/laptop to the terminal of the Debian server and install OMV like this:

    apt-get update
    apt-get upgrade
    apt-get dist-upgrade
    echo "deb arrakis main" > /etc/apt/sources.list.d/openmediavault.list
    apt-get update
    apt-get install openmediavault-keyring postfix
    apt-get update
    apt-get install openmediavault

    And voila you can connect to your OMV-server.

    My suggestion is to jump to OMV v5. Therefore install Debian 10 netinst (also packages "ssh server" and "standard system utilities" at the end) and OMV v5 over it. Here in the forum under "Guides" you will find the description to install OMV v5 over Debian 10. My suggestion don't use the script which is posted here in the forum too. I had problems with the installed flash memory plugin which I didn't need. So do it by hand via terminal.


    After I've posted my thread I checked my two installations files for docker (normal docker and docker-compose) and realized that there were backslash. I removed it and installed everything new and voila docker-compose used the config-folder of the .yml-file.
    Thanks anyway for the hint.

    The issus is now solved.


    with OMV v4 I was running a lot of docker containers without any problems. Now, after the upgrade (to OMV v5) I decided to switch from normal docker to docker compose.
    Therefore I've installed docker and portainer via omv-extras. Furthermore I've updated to the latest docker-compose via CLI (according to GitHub).

    My first docker-compose installation was Plex Media Server. Therefore I've created this docker-compose.yml:

    Under the OMV-GUI I've changed the docker storage path from /var/lib/docker to /srv/dev-disk-by-label-work/appdata.

    After starting of the docker, docker didn't use the stored path of the config folder (which I created before). All of the config files were stored under the docker storage path (before under /var/lib/docker) and not in the folder mentioned in the docker-compose.yml. Under portainer I can see two config-folders:

    The config folder with the long number is located under

    If I stop the container and try to remove the second config-folder (with the long name) I will get an error (via portainer).

    Now my question. How can I solve this issue. Why does docker-compose create a new config-folder instead of using the one mentioned in the .yml file?

    If I do the same with "normal docker" there's no problem. Everything is stored in the folder of the config-file.

    Thanks in advance

    So today I did a fresh installation of Debian 10 again (yesterday I did an UEFI-installation and today a MBR-installation) and OMV via CLI.
    The problem remains. Portainer isn't working with Proxmox-kernel but with the standard kernel without any problems.

    Now I've the question. What is better:
    To stay with the standard-kernel and install the docker containers like they should or use the proxmox-kernel (newer and better stability) and install the docker containers with privileged mode?

    Thanks in advance

    Edit: now I found a topic on the internet that user can breakout from a privileged container and hack the system. Like it was here.

    Did you change the docker path? I don’t and portainer has always worked fine without the privileged flag.

    No, I didn't. As I wrote before, with the standard kernel everything is ok. Only problems with the proxmox kernel.

    The next problem is that I have created a Plex container (docker compose) but it also doesn't start.
    Till I found out by adding the privileged option (mode) Plex started as normal.

    It looks like that there're permission problems. Maybe it has something to do with the proxmox kernel or with the way of installing OMV (via Debian 10 netinst).

    I doubt this line is causing the problem. I'm guessing the volume has corrupt data in it. I would remove portainer from the web interface and the delete the volume (docker volume rm portainer_data). Then I would re-install from the web interface.

    I did a fresh installation of Debian 10 on my system drive. Before I formatted the drive with zeros to be sure everything is "clean". I did this kind of installation twice but the problem with Portainer still remains.

    Somewhere in the internet I found this (terminal-)command:

    docker run -d --name=portainer -p 9000:9000 --privileged --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer -H unix:///var/run/docker.sock

    and this worked. Portainer is up and also shows up on OMV-gui

    I think it has something to do with the permission of the "admin"-user. Without the "--privileged" command Portainer doesn't start

    OMV isn't designed to run alongside a GUI.

    With my "old" system (OMV v4) I had installed Xfce besides OMV (the base install was Debian 9 and afterwards I've installed OMV).
    I didn't face any problems with this system - Debian 9 with Xfce and OMV (side by side). This system was running around one year without any hassles.

    With my "new" system (OMV v5 on Debian 10) I plan to do the same.

    I have the same problem with Portainer. With standard-kernel (4.19) everything runs fine but with Proxmox-kernel v5.3.13-2-pve (latest one) Portainer keeps restarting everytime (by installing via omv-extras).

    As I can see in your signature you're using the Proxmox-kernel too, aren't you? Is Portainer working on your setup (with Proxmox kernel)?
    Do you have any clue why Portainer is not working with the Proxmox kernel?

    Come back to the problem of Squeezebox. Squeezebox needs internal (inside docker) the 9000 port and portainer too.
    Could it be a problem of installing both even you change their external ports? How should docker know to which container the connection should go. For me it looks like that both programs are listing at the same port. How should that work?

    Am I right or do I think completely wrong?

    I don't know if you can do it via OMV-GUI. You can install Portainer by command line:

    docker run -d -p 9001:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

    So Portainer is running under port 9001 instead of 9000 or to say it correctly, the internal port is still 9000 but you can connect from outside via port 9001

    Edit: @geaves was a little faster ;)

    This is the output:

    root@OMV-Testsystem:/var/lib/docker/containers/46f8790ddbbf8aff3188b9b7c286d9a6bd1351a5a984bb9787203e0fd82a7eab# docker container ls
    CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS                          PORTS               NAMES
    46f8790ddbbf        portainer/portainer   "/portainer"        22 minutes ago      Restarting (1) 30 seconds ago                       portainer

    The status seems very wired to me. Because I didn't do anything the last 5 minutes (watching football right now)

    Thanks, this is the message I get, when I run the command:

    docker run portainer

    root@OMV-Testsystem:/var/lib/docker/containers/46f8790ddbbf8aff3188b9b7c286d9a6bd1351a5a984bb9787203e0fd82a7eab# service docker restart
    root@OMV-Testsystem:/var/lib/docker/containers/46f8790ddbbf8aff3188b9b7c286d9a6bd1351a5a984bb9787203e0fd82a7eab# docker run portainer
    Unable to find image 'portainer:latest' locally
    docker: Error response from daemon: pull access denied for portainer, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
    See 'docker run --help'.

    Attached I've the log of the portainer-container. Maybe someone knows what's going on. I've installed Portainer described here

    With the command


    I could fix the problem with the connection to the internet.
    But apt-clean didn't help. I've no access to the webinterface of Portainer. I've tried to install via OMV-GUI and also by hand. No connection to Portainer.
    The installation of Portainer didn't give any errors.
    So no clue what's going on.
    Cockpit runs fine.
    Really funny...