Compose-Plugin and BTRFS

1st Official Post

    I installed the Compose-Plugin and I have it as well as the data running on BTRFS.

    That shouldn't be any issue since docker on BTRFS is officially supported, you only have to add "storage-driver": "btrfs" to the file /etc/docker/daemon.json, which I did, directly after installing the Compose-Plugin.


    Today I happend to look at that file and I saw, that this line had disappeared.

    I don't know when exactly that happened, but I assume, it was when I set the path for docker storage in Services / Compose / Settings.


    If that's the case, maybe it would be better not to completely overwrite the file, but just add the entry for the storage?

    Or maybe add the possibility in the Web-UI to add custom lines (similar to e.g. samba)?

    TerraMaster T6-423

    Qnap TS-853A

    Qnap TS-451+

    Qnap TS-259 Pro+

    Like 1

    Adding custom lines would be good for this, but I can see it being an issue for anyone passing an nvidia card to a container. The nvidia setup modifies the docker.json file outside of omv, so omv is not aware of the change and would overwrite it, unless someone were to copy the nvidia lines back into that field and re-save.


    The only way I could see that being "fool proof" would be if the compose plugin did something like omv does with fstab as an example, where it brackets it's changes between a couple of comments and doesn't change things outside of the comments.

    Asrock B450M, AMD 5600G, 64GB RAM, 6 x 4TB RAID 5 array, 2 x 10TB RAID 1 array, 100GB SSD for OS, 1TB SSD for docker and VMs, 1TB external SSD for fsarchiver OS and docker data daily backups

    Hm, in the official docker documentation it clearly states, that the supported backing filesystem for overlay2 is Ext4 or XFS with ftype=1.

    (see here)


    That's the reason, why I would like to use the recommended btrfs storage driver for BTRFS.

    I don't have enough knowledge of docker to make a sound judgement, if using BTRFS together with overlay2 will cause any problems (in my use case) or not.


    Does anybody know, when the compose plugin writes / recreates daemon.json?

    I did a few tests and so far it wasn't modified.

    TerraMaster T6-423

    Qnap TS-853A

    Qnap TS-451+

    Qnap TS-259 Pro+

    Quote from Krisbee

    Promote overlay2 to be the default storage driver (btrfs and zfs are now opt-in).

    wasn't aware of this one.

    ok, then it shouldn't be a problem.


    Only thing that might be adapted then is the How-To for the Compose-Plugin.

    There it says, that for BTRFS one has to consult the official docs and must do some specific changes to docker.

    If that's no longer the case, that should be removed.

    (that's the reason why I went down that road...)

    TerraMaster T6-423

    Qnap TS-853A

    Qnap TS-451+

    Qnap TS-259 Pro+

    I can understand why chente left the How-TO as is , no one wants to give bad advice. I'm not saying you can't use the docker btrfs storage drive, it's just that is an optional choice. I haven't used btrfs/docker enough, or at scale, to say there are great advantages in using that driver.


    By the way, if you lost your daemon.json edit, AFAIK after editing the /etc/docker/daemon.json file you must immediately restart the docker service and check docker info | grep "Storage Driver:"

    Seems I have created a mess somehow.


    I removed again that line with the storage driver and restarted docker.

    But it doesn't restart.


    I have rebooted and also reinstalled docker (button on Services / Compose), but to no avail.

    Error message is too long to be pasted here. See attached file.




    and this the output from journalctl -xeu docker.service



    any suggestions ?

    Quote from Krisbee

    after editing the /etc/docker/daemon.json file you must immediately restart the docker service and check docker info | grep "Storage Driver:"

    This is exactly what I did at that time. At that time the modification was recognized and visible.

    TerraMaster T6-423

    Qnap TS-853A

    Qnap TS-451+

    Qnap TS-259 Pro+

    It's up and running again.

    This is what I did:


    - removed docker (uninstalled the Compose-Plugin)

    - deleted all the files in the docker dir (didn't touch compose and data files)

    - reinstalled Compose-Plugin

    - in Services / Compose / Settings set the paths again

    - recreated global.env

    - imported the compose files

    - started the containers

    TerraMaster T6-423

    Qnap TS-853A

    Qnap TS-451+

    Qnap TS-259 Pro+

    • Official Post
    Quote from Quacksalber

    Does anybody know, when the compose plugin writes / recreates daemon.json?

    I did a few tests and so far it wasn't modified.

    As the note under the Docker storage field says, if you leave the field blank, the plugin won't change daemon.json. If you do populate the docker storage field, the plugin will rewrite daemon.json whenever you apply changes.


    Quote from Quacksalber

    maybe it would be better not to completely overwrite the file, but just add the entry for the storage?

    If you are able to change the file to customize it, why does the plugin need to maintain one entry?

    omv 8.0.8-1 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.4 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.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!

    Quote from ryecoaaron

    As the note under the Docker storage field says, if you leave the field blank, the plugin won't change daemon.json.

    ok, I must admit, I haven't seen this one... (my bad).


    Quote from ryecoaaron

    If you are able to change the file to customize it, why does the plugin need to maintain one entry?

    I simply was confused here. The How-To on Omv-Extras tells me to set the directories according the examples to prevent future problems.

    It also told me to make specific changes, if I use BTRFS.

    And in one of my first questions I placed in this forum about how OMV deals with custom config changes, I was told, that files that are generated have a header indicating this.


    So I simply didn't expect my changes to this file to disappear.


    But that's no longer an issue now, since I have been told, that the default storage driver is now able to interact with BTRFS.

    TerraMaster T6-423

    Qnap TS-853A

    Qnap TS-451+

    Qnap TS-259 Pro+

    • Official Post
    Quote from Quacksalber

    The How-To on Omv-Extras tells me to set the directories according the examples to prevent future problems.

    It also told me to make specific changes, if I use BTRFS.

    All directories other than docker storage need to be set if you make specific changes. Hence the note.

    Quote from Quacksalber

    And in one of my first questions I placed in this forum about how OMV deals with custom config changes, I was told, that files that are generated have a header indicating this.

    In general, OMV owns the files. There are exceptions where files are partially owned by OMV and/or have no header and/or written by OMV one time and never touched again.

    omv 8.0.8-1 synchrony | 6.17 proxmox kernel

    plugins :: omvextrasorg 8.0.2 | kvm 8.0.4 | compose 8.1.2 | cterm 8.0 | borgbackup 8.0.2 | cputemp 8.0 | mergerfs 8.0 | scripts 8.0.1 | writecache 8.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!

    • Official Post
    Quote from Quacksalber

    I simply was confused here. The How-To on Omv-Extras tells me to set the directories according the examples to prevent future problems.

    It also told me to make specific changes, if I use BTRFS.

    And in one of my first questions I placed in this forum about how OMV deals with custom config changes, I was told, that files that are generated have a header indicating this.


    So I simply didn't expect my changes to this file to disappear.


    But that's no longer an issue now, since I have been told, that the default storage driver is now able to interact with BTRFS.

    I added a note about this in the wiki documentation. Thanks for pointing out the problem. https://wiki.omv-extras.org/do…er_in_omv#plugin_settings

Participate now!

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

Register Yourself Login