When files are copied from one container running on some Virtuozzo server to another container (similar and almost identical in setup or even created as a clone) running on another Virtuozzo server by copying files from the node's environment, ownership information for files can be changed if checked from the target container.
Usually, this can happen in the following scenario:
create a clone of a container and migrate the cloned container:
node1# vzmlocal -C 101:102 node1# vzmigrate root@node2 -e 102
work with original container: create users, groups, change ownership for files to belong to new users; to have users and groups identical in both containers, those containers should use the external authentication - NIS, Active Directory (using Samba or PAM LDAP), etc.;
copy those files to the cloned container by running such commands on the nodes:
node1# tar czf /root/backup.tar.gz -C /vz/root/101/home user1 user2 user3 node1# scp /root/backup.tar.gz root@node2:/root/backup.tar.gz node2# tar xzf /root/backup.tar.gz -C /vz/root/102/home
Every user and group is represented with the corresponding unique UID and GID, and the relation between user and group names with the corresponding IDs differs from one system to another system. Containers have their own relation, hardware nodes have different set of users and groups matching to different UIDs and GIDs.
Thus, when files are put to a backup by the first command on the step 3, the information about users and groups is taken from the point of view of the server
node1. So that, files owned by
user1 in the container #101 can be marked as owned by
user20hn (due to having the same UID for those users), keeping also UID/GID in the backup file for the case when no such user exists in the system during extracting files.
On the server
node2, that user
user20hn could have different UID and it could match to
user2 in the container #102. So, on restoring files by the third command from the step 3, ownership of files can be changed to
user2 from the container's #102 point of view, and if there is no such match for
user2 files then all files from the backup will be owned by a single user
user2 in the container.
The best way to avoid this issue is to copy files from containers: run backup, copy and restore in the containers' context.
If the first way is not possible for some reason and the copying should be done through nodes, backup creation should ignore user and group names and store only UID/GID information.
tar, the option
--numeric-ownershould be used for this, so that the step 3 should look like:
node1# tar --numeric-owner -czf /root/backup.tar.gz -C /vz/root/101/home user1 user2 user3 node1# scp /root/backup.tar.gz root@node2:/root/backup.tar.gz node2# tar xzf /root/backup.tar.gz -C /vz/root/102/home