Docker Compose లో PUID మరియు PGID అంటే ఏమిటి?

PUID మరియు PGID అంటే ఏమిటి

PUID మరియు PGID అనేవి కొన్ని కంటైనర్ ఇమేజ్‌లు ప్రారంభ సమయంలో చదివే రెండు environment variables. Docker వీటిని ఎప్పుడూ పరిశీలించదు. ఇవి linuxserver.io ఇమేజ్‌లు మరియు మరికొన్నింటిలో ఉపయోగించే ఒక పద్ధతి (convention). కాబట్టి, వీటిని చదవడానికి రూపొందించని ఇమేజ్‌లు వీటిని పట్టించుకోవు.

ఒక linuxserver.io ఇమేజ్ లోపల abc అనే వినియోగదారు ఉంటారు. ఇది బిల్డ్ సమయంలో 911 అనే UID (user ID) మరియు 911 అనే GID (group ID) తో సృష్టించబడుతుంది. కంటైనర్ root గా ప్రారంభమై, దాని init scripts ను రన్ చేస్తుంది. ఆ స్క్రిప్ట్‌లలో ఒకటి, మరేదైనా జరగకముందే ఆ వినియోగదారు యొక్క IDని మారుస్తుంది:

groupmod -o -g "${PGID}" abc
usermod -o -u "${PUID}" abc

-o ఫ్లాగ్ ఇప్పటికే వాడుకలో ఉన్న IDని ఉపయోగించడానికి అనుమతిస్తుంది. ఆ తర్వాత init ప్రక్రియ తన అధికారాలను తగ్గించుకుని, abc గా అప్లికేషన్‌ను రన్ చేస్తుంది. కాబట్టి PUID=1000 అనేది Docker కు ఎప్పటికీ చేరదు. ఈ variable అప్లికేషన్ ప్రారంభం కాకముందే కంటైనర్ లోపల ఉన్న వినియోగదారు IDని మారుస్తుంది. దీని అర్థం, ఆ అప్లికేషన్ రాసే ప్రతి ఫైల్ మీ డిస్క్‌పై 1000 అనే IDతో సేవ్ అవుతుంది. PUID ని సెట్ చేయకుండా వదిలేస్తే, abc అనేది 911 గానే ఉంటుంది. అందుకే కాన్ఫిగర్ చేయని bind mount లోని ఫైళ్లు 911:911 యాజమాన్యంతో నిండిపోతాయి.

id తో మీ రెండు నంబర్లను పొందండి

డేటా డైరెక్టరీలకు యజమానిగా ఉన్న యూజర్ ద్వారా, హోస్ట్ మెషీన్‌పై దీన్ని రన్ చేయండి:

id

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo),988(docker)

uid అనేది మీ PUID మరియు gid అనేది మీ PGID. ఒక స్క్రిప్ట్ కోసం, id -u మరియు id -g కేవలం ఆ నంబర్లను మాత్రమే ప్రింట్ చేస్తాయి. చాలా కొత్త VPS ఇమేజ్‌లలో మొదటి హ్యూమన్ అకౌంట్ 1000:1000 గా ఉంటుంది, కానీ అలా ఉంటుందని భావించవద్దు. రీబిల్డ్ చేసిన సర్వర్ లేదా తర్వాత జోడించిన రెండో అకౌంట్ 1001 లేదా అంతకంటే ఎక్కువ నంబర్లను ఇస్తుంది, ఇక్కడ తప్పుడు నంబర్ ఇవ్వడం వల్ల మొత్తం సమస్య వస్తుంది. మీ సేవలు మీ సొంత లాగిన్ యూజర్‌కు బదులుగా ఒక ప్రత్యేక సర్వీస్ అకౌంట్ కింద నడుస్తుంటే, id thatuser రన్ చేసి అక్కడ ఉన్న నంబర్లను తీసుకోండి.

మీ ఫైళ్లు 911:911 గా ఎందుకు కనిపిస్తున్నాయి

ls -l ఆ ID కి సరిపోయే host ఖాతా లేనప్పుడు, పేరుకు బదులుగా సంఖ్యాపరమైన IDని చూపుతుంది. మీ సర్వర్‌లో ఏదీ UID 911 కాదు, కాబట్టి చూపించడానికి పేరు లేదు. ప్రతిసారీ సంఖ్యలను చూడటానికి మరియు అస్పష్టతను తొలగించడానికి ls -ln ఉపయోగించండి:

ls -ln /srv/appdata/sonarr

drwxr-xr-x 2 911 911 4096 Aug  7 09:12 Backups
-rw-r--r-- 1 911 911  512 Aug  7 09:12 config.xml

ఆ output ప్రకారం container built-in defaults తో నడిచింది. ఆ listing లోని config.xml authentication settings ను కలిగి ఉన్న file కూడా. Web UI ను మొదటిసారి తెరిచినప్పుడు ఇది ముఖ్యమైనది, ఎందుకంటే Sonarr మరియు Radarr default username లేదా password లేకుండానే విడుదలవుతాయి. ఊహించకుండా container లోపల నుంచే దీనిని నిర్ధారించండి:

docker exec sonarr id abc
docker compose logs sonarr | head -n 25

linuxserver init దాని ఫలితాన్ని స్టార్టప్ లాగ్‌లో రెండు లైన్లలో ప్రింట్ చేస్తుంది:

User UID:    911
User GID:    911

మీరు మీ Compose ఫైల్‌లో PUID=1000 సెట్ చేసిన తర్వాత కూడా ఆ లైన్లు 911 అని చూపిస్తే, ఆ వేరియబుల్ కంటైనర్‌కు చేరలేదు. సాధారణంగా మీరు docker-compose.yml ని ఎడిట్ చేసి, ఆపై docker compose restart ని రన్ చేయడం వల్ల ఇలా జరుగుతుంది, ఇది పాత ఎన్విరాన్‌మెంట్‌తో ఉన్న కంటైనర్‌నే మళ్లీ ఉపయోగిస్తుంది. ఎన్విరాన్‌మెంట్ మార్పులు అమలు కావాలంటే docker compose up -d అవసరం, ఇది కంటైనర్‌ను మళ్లీ సృష్టిస్తుంది.

కంటైనర్ సృష్టించిన ఫైల్‌ను మీరు ఎందుకు తొలగించలేరు

కర్నల్ పేర్లను కాకుండా సంఖ్యలను మాత్రమే పోల్చి చూస్తుంది. మీ షెల్ UID 1000గా రన్ అవుతుంది. ఆ ఫైల్ UID 911కి చెందినది. దానిని కలిగి ఉన్న డైరెక్టరీ drwxr-xr-x, ఇది కూడా 911కే చెందినది, కాబట్టి గ్రూప్ మరియు ఇతరులకు చదవడానికి (read) మరియు అమలు చేయడానికి (execute) అనుమతి ఉంటుంది కానీ రాయడానికి (write) ఉండదు. ఒక ఫైల్‌ను తొలగించాలంటే ఆ ఫైల్‌పై కాదు, దాని డైరెక్టరీపై రైట్ పర్మిషన్ ఉండాలి, అందుకే ఫైల్ చూడటానికి సాధారణంగా ఉన్నా మీకు ఈ ఎర్రర్ వస్తుంది:

rm: cannot remove '/srv/appdata/sonarr/config.xml': Permission denied

రైట్ చేస్తున్న కంటైనర్ కూడా ఇదే సమస్యను ఎదుర్కొంటుంది. హోస్ట్ డైరెక్టరీ మీ యూజర్‌కు చెందినదై, మోడ్ 755లో ఉండి, అప్లికేషన్ 911గా రన్ అవుతుంటే, దాని మొదటి రైట్ ఆపరేషన్ Permission deniedతో విఫలమవుతుంది మరియు అప్లికేషన్ దాని స్వంత భాషలో ఆ విషయాన్ని తెలియజేస్తుంది. Sonarr లేదా Radarr వంటి .NET అప్లికేషన్లలో ఇది UnauthorizedAccessException: Access to the path '/data/downloads' is deniedగా కనిపిస్తుంది. ఫైల్ ముందు ఉండే పర్మిషన్ స్ట్రింగ్, మీరు ఏ మూడు పర్మిషన్ సెట్‌ల ద్వారా అంచనా వేయబడుతున్నారో తెలియజేస్తుంది, మరియు drwxr-xr-x ను సరిగ్గా చదవడం నేర్చుకుంటే, ఈ ఎర్రర్ ఎందుకు వస్తుందో స్పష్టంగా అర్థమవుతుంది.

ఇది ప్రత్యేకంగా bind mount సమస్య. Docker ఒక empty named volumeను సృష్టించి, ఇమేజ్‌లో ఉన్న పాత్‌పై మౌంట్ చేసినప్పుడు, అది ఆ పాత్‌లోని కంటెంట్‌ను వాల్యూమ్‌లోకి కాపీ చేస్తుంది (ownership మరియు permission bits తో సహా), తద్వారా అప్లికేషన్‌కు అది ఇప్పటికే ఓన్ చేసుకున్న డైరెక్టరీ కనిపిస్తుంది. Bind mount కు ఆ వెసులుబాటు ఉండదు: Docker మీ హోస్ట్ డైరెక్టరీని ఉన్నది ఉన్నట్లుగానే మౌంట్ చేస్తుంది. ఈ తేడా వల్లే bind mount ఎప్పుడు వాడాలి, named volume ఎప్పుడు వాడాలి అన్నది తెలుసుకోవడం చాలా ముఖ్యం.

ఇప్పటికే తప్పుగా ఉన్న డైరెక్టరీని సరిచేయడం

PUID మరియు PGID సెట్ చేయడం వల్ల అప్లికేషన్ ఇకపై చేసే పనులలో మార్పు వస్తుంది. ఇది డిస్క్‌లో ఇప్పటికే ఉన్న ఫైళ్లను వెనక్కి వెళ్లి సరిచేయదు. స్టాక్‌ను ఆపివేసి, యాజమాన్య హక్కులను (ownership) మీరే సరిచేసి, ఆపై మళ్లీ ప్రారంభించండి:

docker compose down
sudo chown -R 1000:1000 /srv/appdata/sonarr
docker compose up -d

మీరు నంబర్లను టైప్ చేయకూడదనుకుంటే sudo chown -R "$(id -u):$(id -g)" /srv/appdata/sonarr ఉపయోగించండి. కంటైనర్ ఆగిపోయినప్పుడు మాత్రమే దీన్ని చేయండి, ఎందుకంటే రికర్సివ్ chown జరుగుతున్నప్పుడు అప్లికేషన్ మధ్యలో ఏదైనా రాస్తుంటే, డైరెక్టరీ ట్రీ సగం మాత్రమే సరిచేయబడి, రెండోసారి గందరగోళకరమైన లోపాలు వచ్చే అవకాశం ఉంది.

PUID మరియు PGID పరిష్కరించలేని సమస్యలు

అన్నీ సరిగ్గా చేసినప్పటికీ చాలామంది ఇబ్బంది పడే అంశం ఇది. linuxserver init ప్రారంభంలో కేవలం మూడు మార్గాలను మాత్రమే chown చేస్తుంది: /app, /config మరియు /defaults. మీ మీడియా మౌంట్లు ఆ జాబితాలో ఉండవు. /data, /downloads మరియు /tv అప్లికేషన్‌కు ఎటువంటి మార్పులు లేకుండానే అందుతాయి. కాబట్టి, ఆ మౌంట్ల హోస్ట్ వైపున కంటైనర్ యూజర్‌కు రాయడానికి అనుమతి లేని యాజమాన్యం (ownership) ఉంటే, కంటైనర్ సజావుగా ప్రారంభమవుతుంది, దాని బ్యానర్‌లో సరైన UIDని చూపిస్తుంది, కానీ మొదటి ఇంపోర్ట్ సమయంలోనే విఫలమవుతుంది.

ఇది సరైన ప్రవర్తనే. ప్రతి కంటైనర్ ప్రారంభంలో పన్నెండు టెరాబైట్ల మీడియా లైబ్రరీపై రికర్సివ్‌గా chown చేయడం విపత్తుకు దారితీస్తుంది. అంటే మీడియా డైరెక్టరీల బాధ్యత మీదే, మరియు అనుమతులు (permissions) వాస్తవానికి తప్పుగా ఉండే మౌంట్లు అవే. కంటైనర్ ఆరోగ్యంగా ఉన్నట్లు కనిపించిన గంటల తర్వాత, అప్లికేషన్ లాగ్‌లలో ఇటువంటి వైఫల్యం నిశ్శబ్దంగా బయటపడుతుంది. కాబట్టి, మీ స్వంత VPSలో ntfyని సెటప్ చేసి, మీ ఫోన్‌కు అలర్ట్‌లను పంపడం ద్వారా, వారాల తరబడి ఎపిసోడ్‌లు మిస్ అయ్యేలోపే ఈ సమస్యను తెలుసుకోవడం ఒక సులభమైన మార్గం.

యూజర్‌ను నియంత్రించడానికి మూడు మార్గాలు మరియు అవి ఎప్పుడు వర్తిస్తాయి

PUID మరియు PGID environment variables

ఇది కేవలం ఎంట్రీపాయింట్ వీటిని చదివే ఇమేజ్‌లపై మాత్రమే పనిచేస్తుంది. కంటైనర్ rootగా ప్రారంభమై, సొంత సెటప్‌ను పూర్తి చేసి, /config ను సరిచేసి, ఆ తర్వాతే ప్రివిలేజ్‌లను తగ్గించుకుంటుంది కాబట్టి ఇది ప్రాచుర్యం పొందింది. Docker Mods మరియు కస్టమ్ init స్క్రిప్ట్‌లు ఇందులో పనిచేస్తాయి. అయితే, ఇది ప్లాట్‌ఫారమ్ ఫీచర్ కంటే ఒక సంప్రదాయంపై ఆధారపడి ఉంటుంది మరియు వేర్వేరు ప్రాజెక్ట్‌లలో ఈ వేరియబుల్ పేర్లు ఒకేలా ఉండవు.

Compose లోని user: కీ

ఇది నిజమైన Docker ఫీచర్. ఇమేజ్ కోడ్ రన్ అవ్వకముందే కంటైనర్ రన్‌టైమ్ దీనిని వర్తింపజేస్తుంది కాబట్టి, ఇది ప్రతి ఇమేజ్‌పై పనిచేస్తుంది:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    user: "1000:1000"

ప్రాసెస్ ఎప్పుడూ rootగా రన్ అవ్వదు, ఇది భద్రత పరంగా మంచిది. అయితే, ఎంట్రీపాయింట్‌లో root అవసరమయ్యే ఏ పనైనా ఇది ఆపేస్తుంది. linuxserver ఇమేజ్‌ల విషయంలో, వారు పరీక్షించిన ఇమేజ్‌లకు మాత్రమే దీనిని సపోర్ట్ చేస్తారు. దీని పరిమితులు ఇవి: PUID మరియు PGID పనిచేయవు, Docker Mods రన్ అవ్వవు, కస్టమ్ సర్వీస్‌లు పనిచేయవు, మరియు మౌంట్ చేసిన ప్రతి వాల్యూమ్ యొక్క అనుమతులకు మీరే బాధ్యత వహించాలి. వారు సూచించిన పద్ధతిలో ఈ ఫ్లాగ్‌తో పాటు రైటబుల్ /run ను వాడాలి:

user: 1000:1000
tmpfs:
  - /run:uid=1000,gid=1000,exec
security_opt:
  - no-new-privileges=true

ఒక చిన్న కాస్మెటిక్ ప్రభావం వినియోగదారులను ఆశ్చర్యపరుస్తుంది. సంఖ్యాపరమైన user: కు కంటైనర్ యొక్క /etc/passwd లో ఎంట్రీ ఉండదు, కాబట్టి లోపల ఉన్న టూల్స్ whoami: cannot find name for user ID 1000 అని చూపిస్తాయి. ID చెల్లుబాటు అవుతుంది మరియు ఫైల్ యాక్సెస్ సాధారణంగానే పనిచేస్తుంది. కేవలం పేరును గుర్తించడం మాత్రమే విఫలమవుతుంది.

Rootless Docker

Rootless Docker లో డెమన్ మీ అన్‌ప్రివిలేజ్డ్ యూజర్‌గా రన్ అవుతుంది, కాబట్టి సర్వర్‌లో ఏదీ నిజమైన rootగా రన్ అవ్వదు. ఇది ఓనర్‌షిప్ లెక్కలను పూర్తిగా మారుస్తుంది. కంటైనర్ UID 0, rootless Docker రన్ చేస్తున్న హోస్ట్ యూజర్ యొక్క UID కి మ్యాప్ అవుతుంది. 1 లేదా అంతకంటే ఎక్కువ ఉన్న ఏదైనా n కోసం కంటైనర్ UID n అనేది subuid + (n - 1) కి మ్యాప్ అవుతుంది. ఇక్కడ subuid అనేది /etc/subuid మరియు /etc/subgid లో మీకు కేటాయించిన రేంజ్ యొక్క బేస్. Docker అక్కడ కనీసం 65,536 సబార్డినేట్ IDలను ఆశిస్తుంది.

ఈ మ్యాపింగ్‌ను మళ్ళీ చదవండి, ఎందుకంటే ఇది సాధారణ సలహాలకు విరుద్ధంగా ఉంటుంది. Rootless Docker లో కంటైనర్ rootగా ఫైల్స్ రాస్తే, అవి మీ ఓనర్‌షిప్‌లో ఉంటాయి. కంటైనర్ UID 1000గా రాస్తే, అవి మీకు యాక్సెస్ లేని సబార్డినేట్ ID (సుమారు 100999) కింద ఉంటాయి. కాబట్టి rootful డెమన్‌లో సరిగ్గా పనిచేసే PUID విలువ ఇక్కడ తప్పు అవుతుంది. ఈ రెండు పద్ధతులు వేర్వేరు పొరలలో ఒకే సమస్యను పరిష్కరిస్తాయి. వీటిని సరిచూసుకోకుండా కలిపి వాడితే, మీరు డిలీట్ చేయడానికి sudo అవసరమయ్యే డైరెక్టరీలను పొందుతారు. మీరు rootless కి మారితే, లైబ్రరీని మైగ్రేట్ చేసే ముందు ఒక ఫైల్‌ను రాసి దాని ఓనర్‌షిప్‌ను పరీక్షించండి.

ఒకే VPS పై నడిచే చాలా self-hosted స్టాక్‌లకు, rootful డెమన్‌పై PUID మరియు PGID వాడటమే సరైన పద్ధతి, ఎందుకంటే ఇమేజ్‌లు దాని కోసమే నిర్మించబడ్డాయి. ఇమేజ్ README లో దీనికి టెస్ట్ చేశామని ఉన్నప్పుడు లేదా PUID సపోర్ట్ లేని అఫీషియల్ అప్‌స్ట్రీమ్ ఇమేజ్ వాడుతున్నప్పుడు మాత్రమే user: ని వాడండి. ఒక VPS పై self-hosted AFFiNE instance వంటి డాక్యుమెంట్ వర్క్‌స్పేస్ చివరి కేటగిరీలోకి వస్తుంది, ఎందుకంటే దాని కంటైనర్లు PUIDని చదవవు. దాని డేటాబేస్ డైరెక్టరీ మరియు అప్‌లోడ్ చేసిన ఫైల్స్ ఓనర్‌షిప్ రన్‌టైమ్ ద్వారానే నిర్ణయించబడుతుంది. self-hosted Chatwoot support desk విషయంలో కూడా ఇదే నిజం; Rails కంటైనర్ మరియు Sidekiq వర్కర్ రెండూ ఒకే అప్‌లోడ్ డైరెక్టరీలోకి రాస్తాయి, కాబట్టి ఆ డైరెక్టరీ ఇమేజ్ రన్ అయ్యే యూజర్‌కు అనుగుణంగా ఉండాలి. కొత్త స్టాక్‌లకు కూడా ఇది మారుదు, కాబట్టి టీమ్‌లోని ప్రతి వ్యక్తికి వారి స్వంత sandboxed OneCLI agent ఇవ్వడం వల్ల వర్క్‌స్పేస్ డైరెక్టరీలు మరియు Postgres డేటా డైరెక్టరీ ఆ ఇమేజ్ రన్ అయ్యే యూజర్ ఓనర్‌షిప్‌లోనే ఉంటాయి, ఇది PUID సమస్య కాదు, user: మరియు chown సమస్య. Codex, Claude Code మరియు Hermes ముందు ఒకే self-hosted API ని ఉంచినప్పుడు కూడా ఇదే అమరిక ఉంటుంది, ఎందుకంటే ఆ ఇమేజ్ దాని సొంత యూజర్‌తో రన్ అవుతుంది మరియు డేటాబేస్, కీలను కలిగి ఉన్న bind mount ఆ యూజర్ ఓనర్‌షిప్‌నే తీసుకుంటుంది.

మీడియా స్టాక్ సందర్భం: కంటైనర్ల మధ్య ఒకే గ్రూపును పంచుకోవడం

ఒక Sonarr, Radarr మరియు డౌన్‌లోడ్ క్లయింట్‌తో కూడిన arr మీడియా స్టాక్ విషయంలో ఇది కేవలం సిద్ధాంతం మాత్రమే కాదు. డౌన్‌లోడ్ క్లయింట్ ఒక పూర్తి చేసిన ఫైల్‌ను /data/downloads లోకి రాస్తుంది. ఆ తర్వాత Sonarr ఆ ఫైల్‌ను /data/media లోకి హార్డ్‌లింక్ చేస్తుంది లేదా తరలిస్తుంది. హార్డ్‌లింక్ పనిచేయాలంటే, ఈ రెండు కంటైనర్లకు ఒకే డైరెక్టరీ ట్రీపై రైట్ యాక్సెస్ ఉండాలి. ఒకవేళ డౌన్‌లోడ్ క్లయింట్ 1000 యూజర్ ఐడితో, Sonarr 1001 యూజర్ ఐడితో నడుస్తుంటే, ఒకరు సృష్టించిన ఫైళ్లను మరొకరు కేవలం చదవగలరు మాత్రమే.

దీనికి పరిష్కారం ఏమిటంటే, స్టాక్‌లోని ప్రతి కంటైనర్ తన PGIDగా ఉపయోగించే ఒక ఉమ్మడి గ్రూపును ఏర్పాటు చేయడం:

sudo groupadd -g 13000 media
sudo usermod -aG media deploy
sudo chown -R deploy:media /srv/media
sudo find /srv/media -type d -exec chmod 2775 {} +
sudo find /srv/media -type f -exec chmod 0664 {} +

2775 లోని ప్రారంభ 2 అనేది setgid బిట్. ఒక డైరెక్టరీపై ఇది ఉంటే, అందులో సృష్టించబడే ప్రతి కొత్త ఫైల్ లేదా సబ్‌డైరెక్టరీ, సృష్టించిన వారి ప్రాథమిక గ్రూపుకు బదులుగా media గ్రూపును వారసత్వంగా పొందుతాయి. దీనివల్ల మీరు ప్రతిసారీ chown రన్ చేయాల్సిన అవసరం లేకుండానే ఫైల్ అనుమతులు సరిగ్గా ఉంటాయి. మీ సొంత యాక్సెస్‌ను తనిఖీ చేసే ముందు, లాగ్ అవుట్ చేసి మళ్ళీ లాగిన్ అవ్వండి లేదా newgrp media రన్ చేయండి: ఎందుకంటే usermod -aG తో జోడించిన గ్రూపు ఇప్పటికే తెరిచి ఉన్న షెల్ సెషన్‌లో కనిపించదు.

కంటైనర్ లోపల, groupmod -o -g 13000 abc అనేది abc గ్రూపును 13000కి మారుస్తుంది, తద్వారా abc మీ హోస్ట్ media గ్రూపుతో సమానమైన GIDతో ఫైళ్లను రాస్తుంది. స్టాక్‌లోని ప్రతి కంటైనర్ తన సొంత PUIDని కలిగి ఉండి, ఈ ఒకే PGIDని పంచుకుంటుంది. ఇందులో లైబ్రరీని కేవలం చదివే కంటైనర్లు కూడా ఉంటాయి, ఉదాహరణకు Jellyfin మరియు Halcyon వంటి ఫ్రంట్ ఎండ్స్, ఇవి ఆ లైబ్రరీని 90ల నాటి వీడియో స్టోర్ లాగా చూపిస్తాయి.

ఆ తర్వాత స్టాక్‌లోని ప్రతి linuxserver కంటైనర్‌లో UMASK=002 సెట్ చేయండి. చాలామంది మర్చిపోయే ముఖ్యమైన దశ ఇది. ఈ ఇమేజ్‌లలో డిఫాల్ట్‌గా UMASK=022 ఉంటుంది, ఇది ప్రతి కొత్త ఫైల్ నుండి గ్రూప్ రైట్ బిట్‌ను తొలగిస్తుంది. దీనివల్ల ఫైళ్లు 0644 అనుమతులతో వస్తాయి మరియు మీరు కాన్ఫిగర్ చేసిన షేరింగ్ పనిచేయదు. 002 సెట్ చేయడం వల్ల ఫైళ్లు 0664 మరియు డైరెక్టరీలు 0775 అనుమతులతో వస్తాయి, తద్వారా గ్రూప్ ఫైళ్లను రాయగలదు:

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
      - TZ=Etc/UTC
    volumes:
      - /srv/appdata/sonarr:/config
      - /srv/media:/data
    restart: unless-stopped

ఈ రెండు విలువలను Compose ఫైల్ పక్కన ఉన్న ఒక .env ఫైల్‌లో ఉంచాలి, తద్వారా మొత్తం స్టాక్ ఒకే నిర్వచనాన్ని చదువుతుంది:

PUID=1000
PGID=13000

Compose ఈ ఫైల్‌ను ${PUID} స్టైల్ సబ్‌స్టిట్యూషన్ కోసం ఆటోమేటిక్‌గా చదువుతుంది, ఇది మీరు క్రెడెన్షియల్స్ కోసం ఉపయోగించే పద్ధతే. docker-compose.yml లో విలువలను ఉంచకుండా .env ఫైల్‌లో ఉంచే అలవాటు ఇక్కడ కూడా వర్తిస్తుంది, అయితే ఈ రెండు సంఖ్యలు రహస్యమైనవి కావు.

కాన్ఫిగరేషన్‌ను నమ్మే బదులు, చివర నుండి చివరి వరకు సరిచూసుకోండి. ఒక కంటైనర్ లోపల నుండి ఒక ఫైల్‌ను రాసి, హోస్ట్ నుండి దాన్ని చదవండి:

docker exec sonarr touch /data/downloads/permtest
ls -ln /srv/media/downloads/permtest

సరైన ఫలితంలో మీ PUID ఓనర్‌గా, 13000 గ్రూపుగా మరియు -rw-rw-r-- మోడ్‌గా కనిపిస్తాయి. ఒకవేళ గ్రూప్ అనుమతులు 1000 అని ఉంటే, ఆ డైరెక్టరీలో setgid బిట్ లేదు అని అర్థం. ఒకవేళ మోడ్ -rw-r--r-- అని ఉంటే, UMASK వేరియబుల్ అమలు కాలేదని అర్థం; అప్పుడు కంటైనర్‌ను రీస్టార్ట్ చేయకుండా, మళ్ళీ క్రియేట్ చేశారో లేదో తనిఖీ చేయండి. పరీక్ష పూర్తయ్యాక rm /srv/media/downloads/permtest తో ఆ ఫైల్‌ను తొలగించండి.

ఏ చిత్రాలు ఏ వేరియబుల్‌ను ఉపయోగిస్తాయి

linuxserver.io చిత్రాలు PUID, PGID మరియు UMASK లను ఉపయోగిస్తాయి. Paperless-ngx ఇదే అంశానికి వేర్వేరు పేర్లను ఉపయోగిస్తుంది: USERMAP_UID మరియు USERMAP_GID, ఇవి రెండూ డిఫాల్ట్‌గా 1000ని కలిగి ఉంటాయి, మరియు వీటిని id -u మరియు id -g నుండి చదవమని దాని డాక్యుమెంటేషన్ సూచిస్తుంది. ఫోటో సర్వర్లు కూడా ఇదే విధమైన వైవిధ్యాన్ని చూపుతాయి: PhotoPrism సొంతంగా PHOTOPRISM_UID మరియు PHOTOPRISM_GID జంటను కలిగి ఉంది, అయితే Immich ఎటువంటి సమానమైన వేరియబుల్‌ను అందించదు మరియు కంటైనర్ వినియోగదారుని Docker యొక్క user: కీకి వదిలేస్తుంది, కాబట్టి PhotoPrism మరియు Immich మధ్య ఎంపిక అనేది మీ సర్వర్‌లోని అతిపెద్ద లైబ్రరీ కోసం మీరు ఏ విధానాన్ని నిర్వహించాలో కూడా నిర్ణయిస్తుంది. సాధారణ డేటాబేస్ మరియు వెబ్ సర్వర్ చిత్రాలతో సహా అనేక అధికారిక అప్‌స్ట్రీమ్ చిత్రాలు, స్థిరమైన అంతర్నిర్మిత వినియోగదారుని కలిగి ఉంటాయి మరియు మీరు user:ని ఉపయోగించాలని లేదా దానిని అలాగే వదిలేయాలని ఆశిస్తాయి. చిన్న సింగిల్-యాప్ డిప్లాయ్‌మెంట్‌లు కూడా ఇదే ప్రశ్నను లేవనెత్తుతాయి, కాబట్టి మీరు self-hosted openGym వర్కౌట్ ట్రాకర్ను సెటప్ చేస్తున్నప్పుడు, దానికి bind mount పాయింట్ చేసే ముందు అది ఏ వినియోగదారుగా రన్ అవుతుందో తనిఖీ చేయడం మంచిది, ఎందుకంటే దాని డేటాబేస్‌ను కలిగి ఉన్న డైరెక్టరీ మీరు PUIDని సెట్ చేసినా చేయకపోయినా ఆ వినియోగదారు అనుమతులనే పొందుతుంది. రిమోట్ యాక్సెస్ రిలే కూడా ఇదే వర్గంలోకి వస్తుంది, కాబట్టి మీరు మీ స్వంత RustDesk రిలే సర్వర్‌ను రన్ చేస్తున్నప్పుడు, మొదటిసారి ప్రారంభించినప్పుడు hbbs రాసే Ed25519 కీ జంట, ఆ చిత్రం ఏ వినియోగదారుతో ముగిసిందో ఆ వినియోగదారు యాజమాన్యంలోనే మీ bind mount లోకి వస్తుంది, మరియు హోస్ట్ వైపున chown మాత్రమే మీకు అందుబాటులో ఉన్న ఏకైక పరిష్కారం. మీరు తర్వాత జోడించే ఇన్‌ఫ్రాస్ట్రక్చర్‌కు కూడా ఇదే వర్తిస్తుంది, కాబట్టి సింగిల్ లాగిన్ కోసం మీ యాప్‌ల ముందు Authentikను ఉంచడం అంటే PUIDని అస్సలు చదవని అధికారిక సర్వర్, Postgres మరియు Redis చిత్రాలను రన్ చేయడం, మరియు వాటి వాల్యూమ్ యాజమాన్యం మీరు కాన్ఫిగర్ చేయగల entrypoint నుండి కాకుండా రన్‌టైమ్ నుండి వస్తుంది.

కాబట్టి ప్రాజెక్ట్‌ల మధ్య ఎన్విరాన్‌మెంట్ బ్లాక్‌ను కాపీ చేసే ముందు ప్రతి చిత్రం యొక్క READMEని తనిఖీ చేయండి. మీరు సెట్ చేసిన ఏదైనా ఎన్విరాన్‌మెంట్ వేరియబుల్‌ను Docker ఏదైనా కంటైనర్‌లోకి పంపుతుంది, లోపల ఏదైనా దానిని చదువుతుందా లేదా అనే దానితో సంబంధం లేకుండా, మరియు ఏదీ ఉపయోగించని PUID ఎటువంటి లోపాన్ని, హెచ్చరికను లేదా ప్రభావాన్ని చూపదు. కంటైనర్ దాని Dockerfile దేనితో ముగిసిందో ఆ వినియోగదారుగా రన్ అవుతుంది, మరియు అది రాసే ఫైళ్ల యాజమాన్యం ద్వారా మీరు దానిని తెలుసుకోవచ్చు. self-hosted open-kritt సెక్యూరిటీ స్కానింగ్ స్టాక్తో సహా, బాక్స్‌కు కొత్తగా ఏదైనా జోడించే ముందు ఆ పని చేయండి, అక్కడ Compose ఫైల్ చిత్రాలు PUIDని గౌరవిస్తాయా లేదా మీరు మౌంట్ చేసే డైరెక్టరీల యాజమాన్యం చిత్రాల ద్వారానే నిర్ణయించబడుతుందా అనేది మీకు తెలియజేస్తుంది.

FAQ

నా Docker ఫైళ్లు 911:911 ఓనర్‌షిప్‌లో ఎందుకు ఉన్నాయి?

911 అనేది linuxserver.io ఇమేజ్‌లలో ఉండే abc యూజర్ యొక్క UID మరియు GID. కంటైనర్ ప్రారంభమైనప్పుడు PUID మరియు PGID సెట్ చేయకపోతే, దాని init స్క్రిప్ట్ డిఫాల్ట్ విలువలను అలాగే ఉంచుతుంది కాబట్టి ఇలా కనిపిస్తుంది. మీ హోస్ట్ మెషీన్‌లో 911 ID కలిగిన అకౌంట్ లేకపోవడం వల్ల, ls -l ఆ నంబర్లను నేరుగా చూపిస్తుంది. PUID మరియు PGID లను id అవుట్‌పుట్‌కు సెట్ చేయండి, docker compose up -d తో కంటైనర్‌ను మళ్లీ సృష్టించండి, ఆపై ప్రభావితమైన డైరెక్టరీపై sudo chown -R 1000:1000 ఉపయోగించి ఫైల్ పర్మిషన్లను సరిచేయండి.

PUID మరియు PGID ప్రతి Docker ఇమేజ్‌లో పనిచేస్తాయా?

లేదు. ఇవి Docker ఫీచర్లు కావు మరియు Docker వీటిని ఎప్పుడూ చదవదు. ఇమేజ్ యొక్క ఎంట్రీపాయింట్ వీటిని చదివి, అప్లికేషన్ ప్రారంభానికి ముందు usermod మరియు groupmod లను కాల్ చేసినప్పుడు మాత్రమే ఇవి పనిచేస్తాయి. ఇది linuxserver.io ఇమేజ్‌లకు మరియు ఈ పద్ధతిని అనుకరించే కొన్ని ప్రాజెక్ట్‌లకు మాత్రమే వర్తిస్తుంది. ఇతర ప్రాజెక్ట్‌లు వేర్వేరు పేర్లను ఉపయోగిస్తాయి, ఉదాహరణకు paperless-ngx లో USERMAP_UID మరియు USERMAP_GID వాడతారు. వీటిని సపోర్ట్ చేయని ఇమేజ్‌లలో, ఈ వేరియబుల్స్ అంగీకరించబడతాయి కానీ ఎటువంటి హెచ్చరిక లేకుండా విస్మరించబడతాయి.

నేను PUID మరియు PGID వాడాలా లేక Docker Compose లో user: కీని వాడాలా?

ఇమేజ్ సపోర్ట్ ఉన్నప్పుడు PUID మరియు PGID వాడండి, ఎందుకంటే ఎంట్రీపాయింట్ root గా రన్ అయ్యి /config ని సరిచేసి, సర్వీసులను సరైన పద్ధతిలో ప్రారంభిస్తుంది. ఇమేజ్‌కు PUID సపోర్ట్ లేనప్పుడు లేదా అది non-root ఆపరేషన్ కోసం పరీక్షించబడిందని README లో పేర్కొన్నప్పుడు user: వాడండి. linuxserver ఇమేజ్‌లో user: సెట్ చేస్తే, PUID మరియు PGID పనిచేయవు, Docker Mods మరియు కస్టమ్ సర్వీసులు ఆగిపోతాయి, మరియు మౌంట్ చేసిన ప్రతి వాల్యూమ్ యొక్క పర్మిషన్లను మీరే నిర్వహించాల్సి ఉంటుంది.

Sonarr కి సరైన PUID ఉన్నప్పటికీ ఫైళ్లను తరలించలేకపోతోంది. సమస్య ఏమిటి?

మూడు విషయాలను వరుసగా తనిఖీ చేయండి. మొదటిది, మీడియా మౌంట్: init స్క్రిప్ట్ కేవలం /app, /config మరియు /defaults లను మాత్రమే chown చేస్తుంది, కాబట్టి /data లేదా /downloads హోస్ట్‌లో ఉన్న ఓనర్‌షిప్‌నే కలిగి ఉంటాయి. రెండవది, షేర్డ్ గ్రూప్: డౌన్‌లోడ్ క్లయింట్ మరియు Sonarr వేర్వేరు GID లతో రన్ అవుతుంటే, ఒకదాని ఫైళ్లను మరొకటి మార్చలేవు, కాబట్టి స్టాక్‌లోని ప్రతి కంటైనర్‌కు ఒకే PGID ఇవ్వండి. మూడవది, umask: ఇమేజ్ డిఫాల్ట్ UMASK=022 ఫైళ్లను 0644 పర్మిషన్లతో రాస్తుంది, ఇందులో గ్రూప్ రైట్ బిట్ ఉండదు, దీనివల్ల షేర్డ్ గ్రూప్ పనిచేయదు. UMASK=002 సెట్ చేయండి మరియు కొత్త ఫైళ్లు గ్రూప్‌ను వారసత్వంగా పొందేలా డైరెక్టరీలపై chmod 2775 తో setgid బిట్‌ను సెట్ చేయండి.