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

Created on 28 Apr 2020  路  6Comments  路  Source: cytopia/devilbox

ISSUE TYPE

  • Bug Report

Checklist

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.

bug

All 6 comments

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.

This issue still occurs...

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 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.

@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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

msyhr picture msyhr  路  7Comments

drupalshift picture drupalshift  路  5Comments

robots4life picture robots4life  路  6Comments

cytopia picture cytopia  路  4Comments

gowrav-vishwakarma picture gowrav-vishwakarma  路  6Comments