Hi @stgraber, just to be sure, so do you mean we dont really need security directory, which it consists apparmor and seccomp rules, did you mean those rules are all in the database?
Regards.
Thanks for the feedback. I tried it and indeed this seems to work on a restore. However if the storage pool is different than the backup you cant use it. (because of naming) Whe can not rename a storage id. I did find a post how to do this in lxd. But for incus this does not work. Any advise on this?
LXD internally uses an SQLite database to store its configuration, so we can always fall back to tampering with its DB manually. This is a bit dangerous, but it seems we have to do it anyway…
$ lxd sql global "UPDATE storage_pools_config SET value='zroot/crypt/var/lib/lxc';"
Rows affected: 3
Note: Please add a WHERE clause to narrow down the records you wish to update if you have multiple storage configurations! I don’t need one because I only have the default storage configured.
In a minute, the storage should become available again:
$ lxc storage list
+---------+--------+-------------------------+-------------+---------+---------+
| NAME | DRIVER | SOURCE | DESCRIPTION | USED BY | STATE |
+---------+--------+-------------------------+-------------+---------+---------+
| default | zfs | zroot/crypt/var/lib/lxc | | 6 | CREATED |
+---------+--------+-------------------------+-------------+---------+---------+
Yeah, all the /var/lib/incus/security/ stuff is generated by Incus when the instance starts based on the instance configuration (its devices, config keys, …).