Issue with docker compose file

  • Hay, Ihave similar bug

    Can you help me, please

    • Offizieller Beitrag

    Moving to a new thread since this is an error with your compose file.


    The error tells you what the problem is. It doesn't like something about line 17. You would have to post your compose file in a code box (very important) for help.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    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!

    • Offizieller Beitrag

    Sorry, I don't know how to do it

    In the OMV GUI in Services>ComposeFiles edit the file in question, copy the text and paste it into the forum. Inside a code box.

  • the command I pasted fixes the error until the next restart.

    Zitat
    sudo killall -9 dnsmasq


    Suggestions welcome




    currently the error looks like this

    • Offizieller Beitrag

    You haven't published your compose file yet.


    In the OMV GUI in Services>ComposeFiles edit the file in question, copy the text and paste it into the forum. Inside a code box.

  • Code
    Is that what it's all about?



  • adguard need to be run on macvlan mode like pihole. this is may working adguardhome, configure first MyMacVlan on composePluging


    • Offizieller Beitrag

    Yeah. That is the compose file. There could be indentation errors that we can't see because you haven't used a code box. If you want us to see those errors, republish the file using a code box.


    That container is mapping port 53. That creates a conflict with OMV. To solve it you can use a vlan. https://wiki.omv-extras.org/do…te_a_vlan_pi-hole_adguard


    You must use the folder path of type /srv/dev_disk_by_uuid_xxxxxxxx, not the one you used.

  • ok, and iunderstand

    • Offizieller Beitrag

    If you really have it like this, all the indentations are missing and that file will not work. Look at the file that raulfg3 published.

  • adguard need to be run on macvlan mode like pihole

    Or just bind the host IP to the port 53

  • - 53:53 / tcp #zwyklyDNS

    - 53:53 / udp #zwyklyDNS

    Code
    - <IP if host>:53:53
  • Just to give some closure on this subject:


    When this type of error happens, be it on adguardhome or pihole, and USER shows lack of knowledge on docker, forcing the idea of a MACVLAN is counter productive and confuses more the USER.

    The easiest solution to the YML is to have the host IP binded to the port 53 and error is cleared.


    An older solution is also to change the /etc/systemd/resolved.conf on the host, as explained here:
    RE: systemd-resolver get port 53 how should i change that safely to use that for pi-hole


    If/when USER finally get's more confortable with docker, then it can be taken to the next level with a proper MACVLAN, isolated net, etc..

    • Offizieller Beitrag

    Just to give some closure on this subject:


    When this type of error happens, be it on adguardhome or pihole, and USER shows lack of knowledge on docker, forcing the idea of a MACVLAN is counter productive and confuses more the USER.

    The easiest solution to the YML is to have the host IP binded to the port 53 and error is cleared.


    An older solution is also to change the /etc/systemd/resolved.conf on the host, as explained here:
    RE: systemd-resolver get port 53 how should i change that safely to use that for pi-hole


    If/when USER finally get's more confortable with docker, then it can be taken to the next level with a proper MACVLAN, isolated net, etc..

    I suppose that solution will work if the container provides OMV with the information it needs through port 53. Otherwise something will not go quite right. Since I don't know what those containers do I can't say if that solution is still valid. I guess if you're saying this it's because it works for you, but keep in mind that the network settings in OMV were changed a few months ago, maybe a year now, and that linked thread predates that change.

    Don't get me wrong, I'm not saying that solution doesn't work, but maybe it's not a universal solution. A vlan network will work in all cases and with any container.

Jetzt mitmachen!

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