Hi, can anyone explain why we specifically only allow Overlay2 as the storage backend for docker?
Cloud we make this configurable?
We have seen issues with different docker storage providers introducing unexpected quirks in the past. For example https://git.cloudron.io/cloudron/box/issues/182 So to keep testing burden low and minimize risk of downtime and app breakage, we settled for now on only supporting overlay2.
Is there any specific reason for you to need something else?
@nebulon My server uses ZFS for most of its storage, so having snapshots etc would be pretty convenient. I can use LVM but other people helping maintain it are big fans of ZFS, and we have the storage and RAM already so it would be pretty nice if we could.
Could we have a parameter or something to let us install it on ZFS without modifying much?
Currently there is no easy way to do that and as mentioned above, unless there are strong reasons, I don't think it makes much sense to support more than overlay2 here, also given that this is the preferred driver from the docker upstream project itself.
But to take a step back, as you mentioned, your server is setup using ZFS for the storage, from the docker docs, I'm not sure this would prevent you from using overlay2 on a ZFS partition, despite being the default there. I might be wrong, since I've never tried that.
Can you try to run the Cloudron install script, let it fail, then restart the docker daemon with
systemctl restart dockerand then run the Cloudron installer again? Just to see if this is just some install script bug to set the storage driver without restarting docker properly?
I have added information here on how to change the graph driver using a systemd drop-in - https://cloudron.io/documentation/storage/#docker-image-location . Please use it at your own risk, since as mentioned, we haven't tested with other graph drivers.