Docker Community Forums

Share and learn in the Docker community.

Cannot start service after image import

Hi,

I was using a docker-compose.yml file to start my containers, and it worked fine until now.
My co-worker just built a new image and I have imported it with a new tag, updated my docker-compose file and tried to restart all my containers with a docker-compose up -d command.

But now I have this error message :

ERROR: for awx_web_1 Cannot start service web: linux spec user: unable to find user root: no matching entries in passwd file

I did research and I found some people with the same message but in their cases they was able to log in the container, in my case I can’t even start it.

I don’t understand where the problem comes from ?

Thanks for helping.

broken image?

In the image the file /etc/passwd seem either broken or deleted.

Since you imported the image, you must have received a tar archive. If you want to analyse the cause, you can extract that tar archive with tar xf {imagename}.tar, repeat the step for the tar archives in the subfolders and take a look to all the files.

Hello,

The /etc/passwd is existing, I’ve found it into one of the image’s layer.

User root seems to be there:

[~]# cat <layer_id>/etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
nginx:x:999:998:Nginx web server:/var/lib/nginx:/sbin/nologin
saslauth:x:998:76:Saslauthd user:/run/saslauthd:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin

And I see nothing wrong about file permissions :

[~]# ls -ltr <layer_id>/etc/passwd
-rw-rw-r-- 1 root root 854 Dec 11  2018 passwd

I don’t get what’s going on.

Just for further information, this is the way I’ve imported the image :

docker import --change ‘CMD ["/bin/sh","-c","/usr/bin/launch_awx.sh"]’ awx-212.tar awx_web:2.1.2

It is important to identify if the file is flagged as deleted in a consequtive layer and thus becomes invisible in the final container.

Though, since you seem to be able to exec into the container, I assume there is no problem with /etc/passwd. It must be something else. This doesn’t realy add up.

I hope your will figure out the problem eventualy.

Also, you might want to consider to introduce a private image registry in your development environment. The only valid reason to manualy save/import images is to prep a dump of final images to transport them to an airgapped production environment’s image registry (usualy gov customers want it that way).

Is there an easy way to do that ?
I’m pretty new with Docker.

I agree with you, we should have a private registry and we plan to do that, but we do a lot of updates to this image that’s why we use import/export at the moment :wink:

If you want an easy setup, try the build-in ones in Gitlab, Nexus3, Artifactory (if you already have one of those already in your environment) or a standalone like Harbor or Artifactory Container Registry. If you should ever consider to use Kubernetes und Helm-Charts: the later two are capable to host Helm-Chart Repos as well.

I highly recommend to use a CI server for this. You can create CI Jobs that are triggered by ‘git push’ (either directly or via webhook) and make it build the image and push it into a private registry for you.

Okay, I figured out what happened.
I tried to import the image in a different machine from which it was created.

If you want to do that, don’t use docker import / docker export, but use docker save / docker load.

As I said I’m very new with Docker so I made the confusion.

Honestly, I would never have expected that someone would use export (which is to export a container state) instead of save. Anyway, the manual approach is highly unrecommended.

Projexts that make the mistake to postpone the setup of proper tooling and automation usualy waste a lot of time with manual, error prone actions. Eventualy this will lead to unnecessary errors and frustrating. Just do it properly in the early stages of your project…