Is there an easy way to edit the container config before the first container start?

[ChrisLuck]

I am trying to create a setup where multiple containers are sharing data via bindmounts as explained in "Method 2" on this page:
https://www.itsembedded.com/sysadmin/proxmox_bind_unprivileged_lxc/

To do so, the uid and gid mapping has to be added to the container's config file.
The tricky part is, that this has to be done before the container is started for the first time otherwise the new mapping can screw up the ownership of already created files.

Is there an easy way to edit the container config before the first container start?

One solution for me would be to "localize" the scripts so that I could clone, edit and execute the local versions.
Can the scripts somehow be easily "localized"? (That would have to replace all github curls with relative paths)

Note:
I am aware of this post which does something similar: #2044
This post should run into the same problem if there are preexisting files for the remapped users/groups.

[ChrisLuck]

The answer I found so far is "No".
There is no easy way to edit the config files before the first container start. Only possible by modifying the scripts.

But I found a different solution for my idmap problem:

• create container with tteck script
• shutdown container
• backup container (uncompressed in my case)
• navigate to /var/lib/vz/dump because that is where the backup is stored
• edit the etc/vzdump/pct.conf file inside of the tar file (see note below)
• restore container from edited backup

NOTE:
When editing the backup it seems to be very important that some specific files stay at the start of the tar.
I unpacked and packed the tar successfully like this:

# do this with the backup tar file being the only file in a temporary directory
tar xpf <backup.tar>
**add new id maps to etc/vzdump/pct.conf**
tar -cf <backup.tar> ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw ./

[zelig2]

I don't feel like it needs to be done before the container is first started. To me the order would be:

• Create new container using tteck scripts
• Shutdown service running in container
• Create any users in the container needed (i.e. to reflect the owner of the shared files)
• Edit the .conf file to add the mount point and do idmapping.
• Reboot container
• Chown the folder in the container

[ChrisLuck]

You are right. When creating a fresh user (that does not own any files yet) this is fine.

In my concrete usecase I want to share nextcloud files with other containers. The files are owned by the existing user www-data (id=33) in nextcloud and during installation, there are hundreds of "www-data"-owned files created.

When I change the mapping after the installation, all files that were previously owned by www-data are now owned by someone else (depends on the new mapping but most likely nobody:nogroup since host id=100033 will no longer be mapped to a container id at all).

The nextcloudpi container will not even start like this. Even if it would, I would have to fix the ownerships of all these files after the new mapping. But also this is not easily possible because now there is no easy way to figure out which of the nobody:nogroup files were owned by www-data:www-data before the mapping.