Docker GUI plugin now stable

  • Oh that could be the solution....i´ve mapped all my Media Drives in the emby container....

    Thanks, i know that i could change the default folder....but i want it on the system drive so it gets backed up when i run a clonezilla session ;)

  • Just going to jump in here and echo what subzero said - it's likely all the leftover container/image data that doesn't get removed with the plugin. Just the same as if you removed docker yourself manually, it will leave all that stuff.

    My suggestion, would be to just first re-enable the plugin. Then once it's enabled (aka docker commands are available) - pull up the command line and run <tt>docker system prune</tt>. This will remove all unused images, volumes, containers, etc. It's a one line command that everyone in the docker world has been waiting for rather than doing old commands searching for lingering containers and contents, piping that into another command to remove, etc. Once done running that - it will also output a "X amount of space reclaimed" information tidbit to indicate how much was cleaned up. Then you should be able to remove the docker plugin and you'll be in good shape. If there is ANYTHING leftover, it's should be small in size and likely just some temp/system files.

  • Ohh, did something change? Last couple times you've made updates with it, I simply uploaded it through the plugins section, checked the updates which showed up, then installed the update. Worked like a charm. No biggie, just curious what would have changed.

    • Official Post

    @nicjo814 there is an issue when using the plugin with zfs systems and the shared folder selector. Iirc this is a bind, since the bind is in fstab the fstab-generator of systemd doesn't know how to create/relate a dependency there since zfs mounts are not fstab related. I haven't been able to confirm this in a testing vm, but there is a thread around. in the future it might be better to remove that option leaving a note to use just a symlink imo.

  • I think you are right @subzero79. I think I saw something about issues with using symlinks, thus I went with the bind option. But that was ages ago and my memory is most probably wrong :)

    I'm using ZFS myself so I'd probably run into this issue when upgrading (soon...) to OMV 3 :)

    EDIT: BTW, creation and deletion of networks is done. Just need to test it properly...

  • I can't make macvlan work on my VirtualBox dev environment (in Ubuntu). Anyone have this working?

    EDIT: The network interface gets created ok withing the container. However I can't access the outside.

    I'm using the PCnet Fast III adapter in promiscuous mode and have tested both bridged and NAT mode... Running out of ideas :(

  • @anderbytes Which parameters would you recommend to be able to set when creating a macvlan network? Right now I have name, subnet, gateway and parent. Anything you feel missing?

    I don't miss anything, either.
    Maybe something will show up after releasing it to public.

    Nonetheless, one of the main features that have to be working so the "network" can be called OK, in my opinion, is that each container can reach other container via it's name, not raw IP.

    Sent from my ASUS_Z017DA using Tapatalk

  • Agree with @anderbytes - I did notice this odd behavior. I thought maybe something was just wrong with my setup, so I created DNS names to resolve to the individual containers (but this is on the physical network) to make this easier. Glad to hear though that it may simply be something related to the actual plugin config.

    @nicjo814 On the macvlan side, I will say that it was a bit tricky originally getting it all configured and understanding that gotchas. Once I figured out creating it manually, I did have to specify the IP (for each container) manually as I was putting it on a real network. It did require setting the IP range for the network, and it did have to be in a real operating network (aka one that exists with gateway etc). The other gotcha that may come into play here, is that when you setup the macvlan network, you can no longer reach the local host from the containers. This is for security purposes. So if you're saying you can't get outbound, make sure to test the actual gateway or something else, not just the local host route. I believe yes this will also affect "localhost" interface as well.

Participate now!

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