WebUI binds to multiple interfaces (IPv4 addresses)

  • Apologies if this has been asked before, I have searched but was unable to turn up anything useful.


    I'm running a virtualised OMV instance (atop Proxmox) configured with two VirtIO NICs, idea being to use one of those interface addresses for Docker containers, the first of which will be a reverse proxy (Nginx).


    Initial tests suggest that OMV binds the WebUI to all interface IPv4 addresses, on ports 80 & 443 (the most useful of ports). How do I prevent this from occurring, is there an option to specify the interface, or if not can this be achieved within some config file? Realise that I could change the default OMV ports and use the reverse proxy, but that feels a bit ugly and perhaps unintuitive from a maintenance standpoint.


    Many thanks

  • as i understand there are no env variables (don't expect the ui to have this also) to change the nginx configuration for the binding address.
    As for now you will have to change the file manually and avoid making changes in the ui that will undo your changes



    cc @votdev

  • Thank you both for your feedback - Appreciate and accept this isn't doable at present, but would like to think future OMV iterations will support the feature.


    I'll investigate the proposed firewall option, if it doesn't block the use of these ports by Docker then it is almost certainly the easiest way to achieve my goal.

  • I'll investigate the proposed firewall option, if it doesn't block the use of these ports by Docker then it is almost certainly the easiest way to achieve my goal.

    Why not move the OMV web interface to a different port?

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Why not move the OMV web interface to a different port?

    You're right, and actually this was something I mused over in my initial post.


    Reflecting on the "firewall" option - I'm not sure how that would work, since it is the binding of the OMV service that causes the problem, rather than clients being able to access the port.

  • You're right, and actually this was something I mused over in my initial post.

    I missed that comment in your initial post. Do you really need the OMV web interface on port 80 or even reverse proxy to it?

    Reflecting on the "firewall" option - I'm not sure how that would work, since it is the binding of the OMV service that causes the problem, rather than clients being able to access the port.

    That seems tough to do. I would avoid the firewall idea as well.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I missed that comment in your initial post. Do you really need the OMV web interface on port 80 or even reverse proxy to it?

    Again you're right, there is no need for the reverse proxy of port 80.


    My idea is to reverse proxy one or two http only services (eg. airsonic) and also several https services that utilise self-signed certificates (including OMV). I'll introduce a LetsEncrypt certificate and a host override on my pfSense DNS resolver to force local traffic to my Nginx instance, which if configured correctly, will serve up everything via one domain name (hope to use routes). I like the idea of this setup since it means certificate management need only happen in one place.


    Unfortunately I am not an expert with Nginx, OMV, LetEncrypt or pfSense ...this should be fun, though painfully aware that I must be careful not to expose the wrong routes/applications to the public web!

Participate now!

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