User ID Change in R4.4.2/Ubuntu 24 Image: rstudio User Now Assigned UID 1001, Causing Incompatibility with R4.4.1

[taiyodayo]

Container image name

rocker/verse:4.4.2

Container image digest

rocker/verse@sha256:730f1963feee28420bb7417658349d627a7a8fa55e906824093245ac82d56b36

What operating system are you seeing the problem on?

Linux

System information

• Docker version 27.3.1, build ce12230

Bug description

Starting from R:4.4.2, the base Ubuntu images were upgraded from Ubuntu 22.04 to Ubuntu 24.04. I noticed that in this updated image, the user ID 1000 is now assigned to the ubuntu user, while the rstudio user has been assigned ID 1001.

This change has caused some containers in our setup to break. Previously, the default user on our host systems also used ID 1000, which allowed seamless bind mounts. Files written by the rstudio user inside the container would align with the host’s default user ID, simplifying permissions management.

To adapt to this new setup, we would need to enable Docker's User Namespace Remapping feature, which requires making several adjustments on each of our hosts, along with elevated privileges (sudo access).

I’m uncertain if this shift in user IDs was intentional. Should we consider this a permanent change, or would it be adjusted in future releases? Knowing this would help us determine if we should update our configuration scripts accordingly.
Thank you!

How to reproduce this bug?

❯ docker run rocker/verse:4.4.1 id -u rstudio
1000
❯ docker run rocker/verse:4.4.2 id -u rstudio
1001

[taiyodayo]

Additional note: In previous builds of Rocker, including those based on Debian, Ubuntu 20.04, and Ubuntu 22.04, the rstudio user was consistently assigned user ID 1000.

[benz0li]

Cross reference:

• [ENH] - Upcoming: Ubuntu ≥ 23.04 (lunar) has user with UID 1000 jupyter/docker-stacks#1877

[taiyodayo]

@benz0li
Thanks for providing the reference! Really impressive that you anticipated this nearly two years ago!
I suspect this change might not be intentional, and I hope the default can be reconsidered as it could impact more users.

[taiyodayo]

in the meantime, I am presenting here my quick fix:

1. delete the ubuntu user (and release user id 1000)
2. re-assign id 1000 to user rstudio

Place this somewhere in the affected Dockerfile

USER root
RUN if [ "$(id -u rstudio)" != "1000" ]; then \
    echo "User rstudio has id other than 1000. Re-assigning id 1000 to user and files." && \
    userdel -r ubuntu && \
    ## Change user rstudio's ID from 1001 to 1000
    usermod -u 1000 rstudio && \
    ## Update ownership of files previously owned by user rstudio
    find / -path /proc -prune -o -user 1001 -exec chown -h 1000 {} + 2>/dev/null || true && \
    ## Update group ownership if necessary
    groupmod -g 1000 rstudio && \
    ## Update ownership of files previously owned by group rstudio
    find / -path /proc -prune -o -group 1001 -exec chgrp -h 1000 {} + 2>/dev/null || true; \
  else \
    ## rocker/rstudio:4.4.1 or earlier does not need this change
    echo "User rstudio already has id 1000. No changes needed."; \
  fi

ideally at the top of Dockerfile, or at the bottom to make quick fix when an built image failed to run for the reason above.

This way I do not need to alter the host environment like I stated above.
(Still I think it is better if this was handled more upstream. )

[jasonheffnerpsu]

watching this as well.. first indication of changing over from 22.04 -> 24.04 was addgroup failing, which needs to be replaced with usermod in our Dockerfile, however changes to the uid would affect mounted filesystems we are using with these base images. Holding off on 4.4.2 pending how this is fixed.

[eitsupi]

Thanks. I do not know the best way to resolve this.
Does anyone know how and why non-root users was added to the base image?
The easiest way is to delete it, but without knowing the history, it is impossible to determine whether it should be deleted.

In any case I don't have the bandwidth to work on this for a while so I would appreciate it if someone could suggest.

[benz0li]

The easiest way is to delete it, but without knowing the history, it is impossible to determine whether it should be deleted.

@eitsupi Don't overthink. Simply delete. See also

• Upgrade to Ubuntu 24.04 Image base jupyter/docker-stacks#2131

[eitsupi]

Thanks, could you check #874?

[benz0li]

Thanks, could you check #874?

@taiyodayo @jasonheffnerpsu Please review #874.

I do not use the Rocker images myself anymore.