Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Solving the ldconfig vs unprivileged user issue

Open
  • Is something wrong?
#189 0 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
shell
Domain
devops, infrastructure

Research direction

Start by reproducing the reported behavior in the tensorflow/tensorflow:2.17.0-gpu-jupyter image as root and UID/GID 1000/1000, using the bashrc startup path and checking ldconfig and nvidia-smi. Determine whether ldconfig is still needed and whether it should run during image build or be removed; done requires a decided startup behavior that avoids the ownership and permission conflict.

Written by the indexing model from the issue text.

Description

sig build dockerfiles

Following up on the problem reported in many places, but for example here at https://github.com/tensorflow/build/commit/8bfbcec2876755e263701b01e568584d4a5db744#r111483861 with a reply by @angerson at https://github.com/tensorflow/build/commit/8bfbcec2876755e263701b01e568584d4a5db744#r111514846 .

So in summary, for e.g. the tensorflow/tensorflow:2.17.0-gpu-jupyter image:

  • If you run the image in interactive mode (using e.g. the command bash when starting the container) and as the default (root) user, you get a startup message warning you that can screw up the ownership of new files created on your volumes. So the user presumably then wants to run it as an unprivileged user.

  • If you then run the image in interactive mode (using e.g. the command bash when starting the container) and as an unprivileged user (e.g. UID/GID 1000/1000), the startup message of the container tells you it's all correct and good, but ldconfig fails to run (giving /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied error message) and perhaps also nvidia-smi will not work at all.

So it's a catch 22, and whichever way you follow the startup recommendations, you're in the wrong :)

  • Should we perhaps stop recommending users to run the software as their own UID/GID and instead just inform them that if they do, file ownership/permissions might be a problem or need attention?

  • Or should we perhaps instead run the ldconfig as part of the image build (while the build is still running as root) instead of in the bashrc file? Or will that not make nvidia-smi work anymore?

  • All that said, if I run the tensorflow/tensorflow:2.17.0-gpu-jupyter image now, I can't even find nvidia-smi installed in it anywhere. Is it still there, or can we just get rid of the ldconfig in bashrc because it's not needed anymore? If so, there's no problem anymore I suppose.

Dominant language
Shell
Stars
310
Forks
141
Avg merge
1h 28m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tensorflow/build

All issues in tensorflow/build

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.