Mailcow-dockerized: Add a configuration option to set the default relative paths for volumes

[JohnGalt1717]

Right now, the volumes for mail including attachments default into the docker folder for this stuff. That's not a good thing because that could grow fast on a system partition. I want to have all of the volumes for this on a dedicated raid volume with more space (and preferably split up certain things across drives for speed.

When I try and alter the docker-compose file to use bind and device paths it ignores it and just puts them in the docker/volumes folder anyhow. IT would be really nice if this was a configuration option in the script and set in the mailcow.conf file with a root volume path and then allowed you to override them.

[MAGICCC]

I am actually not sure, if docker allows certain container using different volume paths. You can either create symbolic links from /var/lib/docker to /foo/bar or using a docker-compose.overide.yml and use bind mounts.

Of course having such an option is nice, but no idea if it's working out-of-the-box

[andryyy]

Hi, there are working instructions in the mailcow docs to redirect these pathes.

Having the volumes in the default lib directory is not a "bad idea". We don't need to fit your installation, you need to think about your partition layout yourself. Either rebind your vmail directory or just mount whatever device to var/lib/docker.

[JohnGalt1717]

@andryyy You're assuming that the host is being used for nothing but Mailcow. It's a horrible idea because the docs that you're referencing only provide one solution (unless there's other docs and if so, please link to the actual doc no "read the doc" which is useless advice).

That solution is to change your entire host configuration to suit mailcow anything else that is running in docker be damned.

The entire point of docker is to issolate mailcow from the host. What you're doing is exactly the opposite.

@MAGICCC You can easily set volumes to be wherever you want. The problem is the setup of the docker-compose file uses shared volumes that aren't setup to define the paths, and thus default to the volumes folder under docker and to change it you're changing your entire docker configuration and not just mailcow.

So either the docker-compose needs to be changed to specify pathing in the shared volumes or it needs to use direct links based on variables in the setup. (Bitwarden does the latter to solve this exact problem.)

This should be reopened and taken seriously, otherwise mailcow is just expecting a dedicated host, which I might as well have installed mailcow on a vm or raw hardware if that's the case, and docker is just in the way, helping nothing.

[andryyy]

I was not.

It was not a horrible idea to move the Docker volume directory. Again: the docs don't even mention this. It was just ONE idea of many possible methods.

Everything is damned? It breaks isolation?! What the? Why? Why are you making this up?

Just browse the mailcow docs. Or read the Docker docs about how to use different volume directories or rebinds. Basic Linux knowledge can get you there, too.

Don't tell anyone that moving the volumes folder to a different device breaks any isolation. That's crap. You can also run any other container on the same machine.

[MAGICCC]

Also volumes != bind mounts

[shiz0]

@JohnGalt1717
Nobody is expecting a dedicated host or anything. You can safely and easily run other containers and also stacks in parallel to mailcow-dockerized!
If you feel like Docker is getting in YOUR way, just use a traditional postfix/dovecot setup maybe...?

Mails and attachments being stored in /var/lib/docker because they are stored in named volumes and their default location is (on Linux) /var/lib/docker/.../, see https://docs.docker.com/storage/volumes/
Docker recommends using these over bind mounts -where you can choose a location- (https://docs.docker.com/storage/bind-mounts/) for various reasons (feel free to read for yourself).
Bitwarden seems to use bind mounts, mailcow-dockerized goes with volumes, as recommended by the docker devs. So this is expected behavior and not a mailcow issue, nor is it a bad idea!

Now I can understand your concern of possibly blocking up a system partition and also your wish to separate different stuff on different disks, but nothing of that requires any change in this project!

There are numerous ways to achieve this and most of them are even written down here, including custom mount points on your host, (sym)linking, and so on. And no, this does not mean changing the path of all docker volumes, if you just mount and link for example /var/lib/docker/volumes/mailcowdockerized_vmail-vol-1/ etc...
Also, if you followed @andryyy 's "useless advice" to "read the docs", you could have found this:
https://mailcow.github.io/mailcow-dockerized-docs/u_e-dovecot-vmail-volume/
which describes how to change the mount point of a named volume. Info, which also ca be found on google, stackoverflow etc... https://stackoverflow.com/questions/38396139/docker-change-folder-where-to-store-docker-volumes

Also I'd like to remind you, that this is an open source project.
I think it's a rather bold move to come here, make false accusations (of broken isolation etc.) and demand unnecessary changes, while
a.) the behavior you deem problematic is actually by design and
b.) tools and workarounds to get what you want already exist in the OS itself or Docker.

Which of those tools you want to use on your system is up to you (and only you). Do your homework and then choose the right tools for your requirement and environment.