Article ID: 117182, created on Sep 8, 2013, last review on May 10, 2014

  • Applies to:
  • Virtuozzo
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor


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:

  1. create a clone of a container and migrate the cloned container:

    node1# vzmlocal -C 101:102
    node1# vzmigrate root@node2 -e 102
  2. 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.;

  3. 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.


  1. The best way to avoid this issue is to copy files from containers: run backup, copy and restore in the containers' context.

  2. 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.

    For tar, the option --numeric-owner should 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

Search Words

wrong permissions

changed owners

a26b38f94253cdfbf1028d72cf3a498b 2897d76d56d2010f4e3a28f864d69223 d02f9caf3e11b191a38179103495106f e8e50b42231236b82df27684e7ec0beb 0dd5b9380c7d4884d77587f3eb0fa8ef

Email subscription for changes to this article
Save as PDF