I have exactly the same problem as the original poster on the newest stable version of OpenVZ.
# vzctl destroy 139 Destroying VE private area: /var/lib/vz/private/139 Can't create tmp dir /var/lib/vz/private/13/vztmp: No such file or directory It seems that the last digit of the three numbers is strangely missing from the tmp dir error. The original poster has the same problem too. I also have a comparable filesystem arrangement due to needing to span across two disks. I have ext3 on /, /var/lib/vz, and /var/lib/vz/private/139. Destroying the 139 node causes the problem shown above. However, destroying any other node works perfectly. So the problem is clearly related to using two or more filesystems for VZ containers. The output of /var/lib/vz and /var/lib/vz/private shows entirely the same information for each directory, essentially a mask of 755 (read-write-execute for the owner, and read-execute for the rest) with root ownership. It doesn't as far as I can see appear to be a permissions problem. A workaround to solve the problem of removing a container is to clear all relevant files from the individual private filesystem (i.e private/139) and then unmount it. After that, you can call the normal destroy command to get rid of all other related files. This works perfectly. Orion -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
