You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm sure there are no duplicate issues or discussions.
I'm sure this feature is not implemented.
I'm sure it's a reasonable and popular requirement.
Description of the feature / 需求描述
Files saved to Local (bind mount) are owned by root, which is inaccessible by me.
Have to manually run chown on those files.
Can you add support for PUID & PGID env vars like linuxserver.io images did?
So those files will be owned by me as a default behavior.
A workaround for now is to use --user $(id -u):$(id -g) when creating containers.
But this approach causes another problem:
when using named volume for /opt/data, using --user approach will cause permission error when alist program access /opt/data, since named volumes are owned by root.
Suggested solution / 实现思路
TBH, I don't know how linuxserver.io team's PUID approach works exactly.
I suspect they run a script to create user with given PID and UID on container creation. And it's that user that owns the application process.
Additional context / 附件
No response
The text was updated successfully, but these errors were encountered:
Please make sure of the following things
Description of the feature / 需求描述
Files saved to Local (bind mount) are owned by root, which is inaccessible by me.
Have to manually run chown on those files.
Can you add support for PUID & PGID env vars like linuxserver.io images did?
So those files will be owned by me as a default behavior.
A workaround for now is to use
--user $(id -u):$(id -g)
when creating containers.But this approach causes another problem:
when using named volume for
/opt/data
, using--user
approach will cause permission error when alist program access/opt/data
, since named volumes are owned by root.Suggested solution / 实现思路
TBH, I don't know how linuxserver.io team's PUID approach works exactly.
I suspect they run a script to create user with given PID and UID on container creation. And it's that user that owns the application process.
Additional context / 附件
No response
The text was updated successfully, but these errors were encountered: