- Más nuevo
- Más votos
- Más comentarios
Hi there,
You can provide your own password and group files in your container image by copying them to the correct location in your Dockerfile. The COPY command you have included in your question appears to be correct, so it's likely that the issue is with how the files are being used at runtime.
One thing to check is whether the user that is trying to run dbus has the correct permissions to read and use the password and group files that you have provided. You can check this by running ls -l /etc/passwd and ls -l /etc/group in your container to see who has permission to read and write to these files.
Additionally, it's worth checking whether the messagebus user that dbus is trying to use actually exists in your /passwd file. You can do this by running grep messagebus /etc/passwd to see if the user is listed in the file. If the user does not exist, dbus will not be able to start as it will not be able to get the UID and GID for the messagebus user.
Finally, it's possible that dbus is not able to start because it is not being run with the correct privileges. The dbus daemon typically requires root privileges to start, so you may need to run your dbus command with sudo to give it the necessary privileges. For example:
sudo dbus-daemon --config-file=/usr/share/dbus-1/system.conf
This should allow dbus to start properly and use the passwd and group files that you have provided in your container.
Hope this helps!
Contenido relevante
- OFICIAL DE AWSActualizada hace 5 meses
- OFICIAL DE AWSActualizada hace 2 años
It seems clear on further testing that /etc/passwd is NOT being replaced as expected, although /etc/group is replaced as expected. "ls -l /etc/passwd" is showing a timestamp of October for this file, while /etc/group is showing a current timestamp. So, it seems there's something else required here to get the "messagebus" user into the password file.