How do I run docker container as exact user on host?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
On my host I have the user 'appuser', and in my dockerfile I create the user 'appuser'.
1) Lets say my program takes in a single file from /tmp/a/ and outputs a new file to /tmp/b/ which are passed as volumes to the container from the host.
2) As appuser on the host I create /tmp/a/test.txt, but the outputted file has permissions 'polkitd:libstoragemgmt' for some reason instead of 'appuser:appuser'.
How can I get make sure the outputted file will have 'appuser' permissions (same user running program inside container)?
docker docker-volume volumes
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
add a comment |
On my host I have the user 'appuser', and in my dockerfile I create the user 'appuser'.
1) Lets say my program takes in a single file from /tmp/a/ and outputs a new file to /tmp/b/ which are passed as volumes to the container from the host.
2) As appuser on the host I create /tmp/a/test.txt, but the outputted file has permissions 'polkitd:libstoragemgmt' for some reason instead of 'appuser:appuser'.
How can I get make sure the outputted file will have 'appuser' permissions (same user running program inside container)?
docker docker-volume volumes
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
add a comment |
On my host I have the user 'appuser', and in my dockerfile I create the user 'appuser'.
1) Lets say my program takes in a single file from /tmp/a/ and outputs a new file to /tmp/b/ which are passed as volumes to the container from the host.
2) As appuser on the host I create /tmp/a/test.txt, but the outputted file has permissions 'polkitd:libstoragemgmt' for some reason instead of 'appuser:appuser'.
How can I get make sure the outputted file will have 'appuser' permissions (same user running program inside container)?
docker docker-volume volumes
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
On my host I have the user 'appuser', and in my dockerfile I create the user 'appuser'.
1) Lets say my program takes in a single file from /tmp/a/ and outputs a new file to /tmp/b/ which are passed as volumes to the container from the host.
2) As appuser on the host I create /tmp/a/test.txt, but the outputted file has permissions 'polkitd:libstoragemgmt' for some reason instead of 'appuser:appuser'.
How can I get make sure the outputted file will have 'appuser' permissions (same user running program inside container)?
docker docker-volume volumes
docker docker-volume volumes
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
asked Nov 23 '18 at 19:42
Stephen PersonStephen Person
32
32
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The user inside of the container does not exist on the host, what is shared between the two environments is the UID/GID. So inside the container, the UID may map to appuser while on your host that same UID may map to polkitd. If you look at your /etc/passwd file on the host and container, you'll see that they likely do not match. This is only really visible when you use a host mount since the file owners are visible in that scenario on the host.
One solution you could try is mounting the /etc/passwd and /etc/group from the host to the container so that you have the same users and groups on each side, but this has the downside that the image could be build with a user that does not exist on the host, or if it does exist, it may be with different UID/GID values, making the files on the filesystem owned by the wrong users.
My personal solution is to adjust the UID/GID inside the container to match the user on the host using a script I run inside my entrypoint. It compares the owner of a file or directory you mount as a volume to that of the user inside the container, and when they do not match, the container user is modified. You need to start the container as root for this, but you can drop from root to your appuser at the end of the entrypoint to run the container command (I typically use exec + gosu for this). You can find a script for this, fix-perms, along with an example in my base image repo at https://github.com/sudo-bmitch/docker-base.
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53452192%2fhow-do-i-run-docker-container-as-exact-user-on-host%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The user inside of the container does not exist on the host, what is shared between the two environments is the UID/GID. So inside the container, the UID may map to appuser while on your host that same UID may map to polkitd. If you look at your /etc/passwd file on the host and container, you'll see that they likely do not match. This is only really visible when you use a host mount since the file owners are visible in that scenario on the host.
One solution you could try is mounting the /etc/passwd and /etc/group from the host to the container so that you have the same users and groups on each side, but this has the downside that the image could be build with a user that does not exist on the host, or if it does exist, it may be with different UID/GID values, making the files on the filesystem owned by the wrong users.
My personal solution is to adjust the UID/GID inside the container to match the user on the host using a script I run inside my entrypoint. It compares the owner of a file or directory you mount as a volume to that of the user inside the container, and when they do not match, the container user is modified. You need to start the container as root for this, but you can drop from root to your appuser at the end of the entrypoint to run the container command (I typically use exec + gosu for this). You can find a script for this, fix-perms, along with an example in my base image repo at https://github.com/sudo-bmitch/docker-base.
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
add a comment |
The user inside of the container does not exist on the host, what is shared between the two environments is the UID/GID. So inside the container, the UID may map to appuser while on your host that same UID may map to polkitd. If you look at your /etc/passwd file on the host and container, you'll see that they likely do not match. This is only really visible when you use a host mount since the file owners are visible in that scenario on the host.
One solution you could try is mounting the /etc/passwd and /etc/group from the host to the container so that you have the same users and groups on each side, but this has the downside that the image could be build with a user that does not exist on the host, or if it does exist, it may be with different UID/GID values, making the files on the filesystem owned by the wrong users.
My personal solution is to adjust the UID/GID inside the container to match the user on the host using a script I run inside my entrypoint. It compares the owner of a file or directory you mount as a volume to that of the user inside the container, and when they do not match, the container user is modified. You need to start the container as root for this, but you can drop from root to your appuser at the end of the entrypoint to run the container command (I typically use exec + gosu for this). You can find a script for this, fix-perms, along with an example in my base image repo at https://github.com/sudo-bmitch/docker-base.
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
add a comment |
The user inside of the container does not exist on the host, what is shared between the two environments is the UID/GID. So inside the container, the UID may map to appuser while on your host that same UID may map to polkitd. If you look at your /etc/passwd file on the host and container, you'll see that they likely do not match. This is only really visible when you use a host mount since the file owners are visible in that scenario on the host.
One solution you could try is mounting the /etc/passwd and /etc/group from the host to the container so that you have the same users and groups on each side, but this has the downside that the image could be build with a user that does not exist on the host, or if it does exist, it may be with different UID/GID values, making the files on the filesystem owned by the wrong users.
My personal solution is to adjust the UID/GID inside the container to match the user on the host using a script I run inside my entrypoint. It compares the owner of a file or directory you mount as a volume to that of the user inside the container, and when they do not match, the container user is modified. You need to start the container as root for this, but you can drop from root to your appuser at the end of the entrypoint to run the container command (I typically use exec + gosu for this). You can find a script for this, fix-perms, along with an example in my base image repo at https://github.com/sudo-bmitch/docker-base.
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
The user inside of the container does not exist on the host, what is shared between the two environments is the UID/GID. So inside the container, the UID may map to appuser while on your host that same UID may map to polkitd. If you look at your /etc/passwd file on the host and container, you'll see that they likely do not match. This is only really visible when you use a host mount since the file owners are visible in that scenario on the host.
One solution you could try is mounting the /etc/passwd and /etc/group from the host to the container so that you have the same users and groups on each side, but this has the downside that the image could be build with a user that does not exist on the host, or if it does exist, it may be with different UID/GID values, making the files on the filesystem owned by the wrong users.
My personal solution is to adjust the UID/GID inside the container to match the user on the host using a script I run inside my entrypoint. It compares the owner of a file or directory you mount as a volume to that of the user inside the container, and when they do not match, the container user is modified. You need to start the container as root for this, but you can drop from root to your appuser at the end of the entrypoint to run the container command (I typically use exec + gosu for this). You can find a script for this, fix-perms, along with an example in my base image repo at https://github.com/sudo-bmitch/docker-base.
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
answered Nov 23 '18 at 19:53
BMitchBMitch
69.1k10153169
69.1k10153169
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53452192%2fhow-do-i-run-docker-container-as-exact-user-on-host%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
