Mounting a volume over existing data

Ibragim_Ganizade · April 24, 2025, 5:17pm

Hi!

I have a YAML file for distrobuilder that sets up MariaDB in an image. Now, I need to attach a volume to the container at /var/lib/mysql, but I’ve run into an issue.

I don’t want the volume to overwrite any existing data in the container. For example, Docker has a way to avoid this behavior, as described in Docker’s documentation.

I haven’t found anything like this in the distrobuilder or Incus documentation. Is there a flag or feature that prevents a volume from being mounted over existing data? Or is this something that might be implemented in future versions?

Any guidance would be appreciated!

Thanks!

osch · April 28, 2025, 2:45am

As far as I am aware there isn’t such a feature in Incus, might be worth to create a feature ticket for it. From my understanding of the provided link you can perform the same steps manually.

create a new storage volume in incus
attach that volume to your container under /tmp/volume
copy or move all data from /var/lib/mysql to /tmp/volume
reattach the volume to /var/lib/mysql
start your container

This is the only way you can recreate the pointed out Docker feature. Think having similar functionality in Incus would be a great addition.

Ibragim_Ganizade · April 28, 2025, 12:47pm

Hey, thanks a ton for the ideas!

@stgraber — do you think adding a feature like Docker’s volume mounting behavior would make sense for Incus? Manual copying doesn’t really scale with many containers.

Thanks!

stgraber · April 28, 2025, 9:49pm

github.com/lxc/incus

Add tmpfs support for disk devices

opened 04:43PM - 21 Mar 25 UTC

huoxingdawang

Documentation Easy API

I noticed that Incus has recently supported OCI images, like Docker, and I reall…y like this feature. However, I noticed that many Docker configurations include something like `--mount type=tmpfs,target=/tmp/cache,tmpfs-size=1000000000` to create a temporary directory within the container. Currently, a feasible alternative may be to map all containers to the host's tmpfs using the "path" mode. But if all containers share the same directory on the host, some containers may not work properly. For example, multiple copies of the same application would try to access the same directory. If each container has its own tmpfs on the host, I need to manually create all the directories, which is inconvenient to maintain. And for both methods, after restart the containe, the files will be kept rather than deleted. For system containers with complete distributions, I can create tmpfs within the container, such as editing `/etc/fstab`. But this approach doesn't seem effective for applications, as they do not handle the content in `/etc/fstab`. I'm not sure if there's already a solution for this, but if not, I suggest adding tmpfs support for disk devices. For example, the configuration could look like this, and we can get a 8GB temporary directory within the container: ```yaml devices: tmpfs: path: /tmp source: tmpfs size: 8GB type: disk ```

Ibragim_Ganizade · April 29, 2025, 2:23am

Thanks for the link @stgraber !

I had a look at issue #1822, but it seems to focus on tmpfs support rather than on preserving existing container data when mounting a new volume.
Would it make sense to open a separate feature request specifically for that behavior?

Thanks again for your help!