Podman restore container failed
*HI,* *When I migrated a podman container from a google cloud rhel 8.3 vm to a local rhel 8.3 vm, I got the following error when restoring (Checkpoint and restore podman uses CRIU): * persmision:1: Error (criu/files-reg.c:2182): File . has bad mode 040755 (expect 040555) (00.343223) 1: Error (criu/files.c:1357): Can't open root (00.343659) Error (criu/cr-restore.c:1560): 163252 exited, status=1 (00.343707) Warn (criu/cr-restore.c:2469): Unable to wait 163252: No child processes (00.343974) mnt: Switching to new ns to clean ghosts (00.344242) Error (criu/cr-restore.c:2483): Restoring FAILED. *And from the local rhel 8.3 vm to the google cloud rhel 8.3 vm, I got:* bad mode 040555 (expect 040755) *So bad mode in reverse.* *Any ideas on how to do a workaround? not necessarily a permanent fix.* *The container is a podman container: quay.io/adrianreber/counter <http://quay.io/adrianreber/counter>* -- Best regards, Ali Hamieh, PhD *LinkedIn <https://www.linkedin.com/in/ali-hamieh-phd/>ResearchGate <https://www.researchgate.net/profile/Ali_Hamieh>*
On Tue, Jun 15, 2021 at 01:45:43PM -0400, Ali Hamieh wrote:
*When I migrated a podman container from a google cloud rhel 8.3 vm to a local rhel 8.3 vm, I got the following error when restoring (Checkpoint and restore podman uses CRIU): * persmision:1: Error (criu/files-reg.c:2182): File . has bad mode 040755 (expect 040555) (00.343223) 1: Error (criu/files.c:1357): Can't open root (00.343659) Error (criu/cr-restore.c:1560): 163252 exited, status=1 (00.343707) Warn (criu/cr-restore.c:2469): Unable to wait 163252: No child processes (00.343974) mnt: Switching to new ns to clean ghosts (00.344242) Error (criu/cr-restore.c:2483): Restoring FAILED.
*And from the local rhel 8.3 vm to the google cloud rhel 8.3 vm, I got:* bad mode 040555 (expect 040755) *So bad mode in reverse.*
*Any ideas on how to do a workaround? not necessarily a permanent fix.*
*The container is a podman container: quay.io/adrianreber/counter <http://quay.io/adrianreber/counter>*
We talked about this already. The main question here is, independent of checkpoint/restore, why does the same image has 555 for the root directory on one host and 755 on another host? How does Podman decide the mode for '.' of the container's root directory. Once you can fix/change that the container migration should just work. Does anyone know how the mode of the container's root directory is configured? Adrian
On 6/16/21 02:36, Adrian Reber wrote:
*When I migrated a podman container from a google cloud rhel 8.3 vm to a local rhel 8.3 vm, I got the following error when restoring (Checkpoint and restore podman uses CRIU): * persmision:1: Error (criu/files-reg.c:2182): File . has bad mode 040755 (expect 040555) (00.343223) 1: Error (criu/files.c:1357): Can't open root (00.343659) Error (criu/cr-restore.c:1560): 163252 exited, status=1 (00.343707) Warn (criu/cr-restore.c:2469): Unable to wait 163252: No child processes (00.343974) mnt: Switching to new ns to clean ghosts (00.344242) Error (criu/cr-restore.c:2483): Restoring FAILED.
*And from the local rhel 8.3 vm to the google cloud rhel 8.3 vm, I got:* bad mode 040555 (expect 040755) *So bad mode in reverse.*
*Any ideas on how to do a workaround? not necessarily a permanent fix.*
*The container is a podman container: quay.io/adrianreber/counter <http://quay.io/adrianreber/counter>* We talked about this already. The main question here is, independent of checkpoint/restore, why does the same image has 555 for the root
On Tue, Jun 15, 2021 at 01:45:43PM -0400, Ali Hamieh wrote: directory on one host and 755 on another host? How does Podman decide the mode for '.' of the container's root directory.
Once you can fix/change that the container migration should just work.
Does anyone know how the mode of the container's root directory is configured?
Adrian _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
The mode is based on the underlying storage merge directory. Which I believe is based on the images top level directory.
On Wed, Jun 16, 2021 at 08:40:39AM -0400, Daniel Walsh wrote:
The mode is based on the underlying storage merge directory. Which I believe is based on the images top level directory.
The permissions for a container's rootfs are inherited from the image that was used to create it, and in that image's layers, we've defaulted each one to inheriting the permissions of its parent layer. For images like ubi8, which include the root directory itself, this means we preserve what it intended. For images like fedora, which don't, they get the default. At least, that's how it's worked with overlay since storage v1.24. Before that, I think that every layer started with a root directory with 0755 permissions, and if a layer was populated with a root directory with some other permissions, layers based on that layer did not inherit those permissions. This applied to the read-write layers of containers as well, so you'd see 0755 even if, like in the ubi8 image, you were supposed to get 0555. Depending on which software was used to pulled the image, you might still see the effects of the old behavior. HTH, Nalin
Hi Daniel, Is there a solitiom to make it work for my case. Just to change the permissions manually with commands on the source of the migration to make it mode compatible? What directory i need to chmod? Sent from my iPhone
On Jun 18, 2021, at 10:58 AM, Nalin Dahyabhai <nalin@redhat.com> wrote:
On Wed, Jun 16, 2021 at 08:40:39AM -0400, Daniel Walsh wrote:
The mode is based on the underlying storage merge directory. Which I believe is based on the images top level directory.
The permissions for a container's rootfs are inherited from the image that was used to create it, and in that image's layers, we've defaulted each one to inheriting the permissions of its parent layer.
For images like ubi8, which include the root directory itself, this means we preserve what it intended. For images like fedora, which don't, they get the default.
At least, that's how it's worked with overlay since storage v1.24.
Before that, I think that every layer started with a root directory with 0755 permissions, and if a layer was populated with a root directory with some other permissions, layers based on that layer did not inherit those permissions.
This applied to the read-write layers of containers as well, so you'd see 0755 even if, like in the ubi8 image, you were supposed to get 0555.
Depending on which software was used to pulled the image, you might still see the effects of the old behavior.
HTH,
Nalin _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
participants (4)
-
Adrian Reber -
Ali Hamieh -
Daniel Walsh -
Nalin Dahyabhai