Past mounts are persisted through stop/start cycles
Description
Instructions:
- Stop the lima instance
- Change your home mount point
mounts:
- location: "~"
- mountPoint: "/home/development"
+ mountPoint: "/home/trojan1"
writable: true
- Start the lima instance
- Repeat with
/home/trojan2,/home/trojan3,/home/trojan4
After doing this 4 times:
/home/trojan1is empty (not mounted) and owned by root/home/trojan2is empty (not mounted) and owned by root/home/trojan3is mounted and owned by $USER/home/trojan4is mounted and owned by $USER
$ ls -lA /home
total 5
drwxr-sr-x 2 alpine alpine 1024 Jan 28 14:51 alpine
drwxr-xr-x 3 root root 1024 May 25 13:16 development
drwxr-xr-x 3 development development 1024 May 25 12:49 development.linux
drwxr-xr-x 2 root root 1024 May 25 13:04 trojan1
drwxr-xr-x 2 root root 1024 May 25 13:13 trojan2
drwx------ 11 development development 320 May 25 13:22 trojan3
drwx------ 11 development development 320 May 25 13:22 trojan4
$ mount | grep ^mount
mount0 on /home/trojan3 type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
mount0 on /home/trojan4 type virtiofs (rw,relatime)
Discussion: #2359
Configuration:
disk: "15GiB"
mountType: "virtiofs"
mounts:
- location: "~"
mountPoint: "/home/development"
writable: true
- location: "/tmp/lima"
writable: true
vmType: "vz"
os: "Linux"
arch: "aarch64"
audio:
device: "vz"
video:
display: "none"
networks:
- vzNAT: true
images:
- location: "https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/cloud/nocloud_alpine-3.19.1-aarch64-uefi-cloudinit-r0.qcow2"
digest: "sha512:d5e69cff0ecb0fd3850bd78f56f66131115934df27b2373c35a85a74b9def52822134dd43f90b4fabe239fdd4452026cb45f1c8f0b36a43af69335a26f0959b5"
arch: "aarch64"
containerd:
system: false
user: false
If I change the mount point back to the original (a mountPoint that was already used) the previous mountPoint is still mounted:
mounts:
- location: "~"
- mountPoint: "/home/trojan4"
+ mountPoint: "/home/development"
writable: true
$ mount | grep ^mount
mount0 on /home/trojan4 type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
mount0 on /home/development type virtiofs (rw,relatime)
The original does get the correct permissions and contents:
$ ls -ld /home/development
drwx------ 11 development development 352 May 25 13:33 /home/development
Another stop/start makes the instance forget the previous mount:
$ mount | grep ^mount
mount0 on /home/development type virtiofs (rw,relatime)
mount1 on /tmp/lima type virtiofs (rw,relatime)
Is it important to remove the empty directories ? We could add some rmdir code, matching the mkdir.
https://github.com/lima-vm/lima/blob/v0.22.0/pkg/cidata/cidata.TEMPLATE.d/boot/25-guestagent-base.sh#L11
https://github.com/lima-vm/lima/blob/v0.22.0/pkg/cidata/cidata.TEMPLATE.d/boot/05-lima-disks.sh#L31
EDIT: Not sure what VZ is doing, only know QEMU
Supposedly one could add some systemd script to clean up the mount points, and something similar for openrc
https://www.freedesktop.org/software/systemd/man/latest/systemd-poweroff.service.html
/usr/lib/systemd/system-shutdown/lima.shutdown
/etc/local.d/lima.stop
EDIT: Nope, these scripts are run when all filesystems are unmounted (or read-only), so too late to clean up there
Is it important to remove the empty directories ? We could add some
rmdircode, matching themkdir.
We could, as long as we only remove empty directories (and ignore errors when they are not empty).
We cannot force-remove the mount point because it may exist with content the user wants to keep, and it was only temporarily shadowed by a mount.
I think rmdir should be OK (leave files and fail), but the timing is tricky...
I was trying with a "lazy" (fuser)unmount, but any processes using it needs to be stopped first