'Failed to change ownership of the home directory' in PHP container

[Venorcis]

ISSUE TYPE

• Bug Report

Checklist

• .env file is attached
• docker-compose.override.yml is attached (if it exists)
• Custom configs from cfg/ dir are attached (if customized)
• docker-compose logs and log/ output is added
• I've looked through the docs: https://devilbox.readthedocs.io/en/latest/
• I've looked through existing issues: https://github.com/cytopia/devilbox/issues
• I've read troubleshooting: https://devilbox.readthedocs.io/en/latest/support/troubleshooting.html

OS / ENVIRONMENT

1. Host operating system and version: Windows 10
2. (Windows) Native Docker or Docker Toolbox: Docker Toolbox
3. Docker version: 19.03.1
4. Docker Compose version: 1.24.1
5. (Linux) Is SELinux enabled?: n/a
6. What git commit hash are you on?: 8c931cd

SUMMARY

Trying to start the PHP (7.4) container for the first time fails. A work-around is to start it a second time, and then it works again.

STEPS TO REPRODUCE

• Start from scratch (or execute 'docker-compose down' first)
• Call 'docker-compose up php' (with PHP_SERVER set to 7.4)

EXPECTED BEHAVIOUR

The php server starts without issue.

ACTUAL BEHAVIOUR

The following output is reported:

php_1               | [INFO] Debug level: 2
php_1               | [INFO] Changing user 'devilbox' uid to: 197610
php_1               | root $ usermod -u 197610 devilbox
php_1               | usermod: Failed to change ownership of the home directory
docker_php_1 exited with code 12

Execution is halted at this point; the php server does not start correctly.

OTHER INFORMATION

If this error occurs, these steps are a work-around to allow the php server to start anyway:

• docker-compose stop
• docker-compuse up php

The output is then:

php_1               | [INFO] Debug level: 2
php_1               | [INFO] Changing user 'devilbox' uid to: 197610
php_1               | root $ usermod -u 197610 devilbox
php_1               | usermod: no changes

So in summary, the second start (when uninterrupted by a 'down' or a full toolbox restart) always works.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Venorcis]

This issue still occurs...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cytopia]

@Venorcis I finally figure out the issue and will provide a fix shortly:

grep -E '^(U|G)ID_M(IN|AX)' /etc/login.defs
UID_MIN                  1000
UID_MAX                 60000
GID_MIN                  1000
GID_MAX                 60000

It turns out, that the given user id was above the acceptable threshhold value.

[cytopia]

@Venorcis I finally figure out the issue and will provide a fix shortly:

grep -E '^(U|G)ID_M(IN|AX)' /etc/login.defs
UID_MIN                  1000
UID_MAX                 60000
GID_MIN                  1000
GID_MAX                 60000

It turns out, that the given user id was above the acceptable threshhold value.

Turns out it is totally unrelated. The actual fix is to run usermod twice in case it fails during the first try. The second run always succeeds. Found this issue in a lot of other docker projects. It is a bit messy, but it does the job

[cytopia]

Fixed here: #750