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

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

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

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

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

-o ఫ్లాగ్ ఇప్పటికే వాడుకలో ఉన్న IDని ఉపయోగించడానికి అనుమతిస్తుంది. ఆ తర్వాత, init ప్రక్రియ తన అధికారాలను తగ్గించుకుని (drops privileges), అప్లికేషన్‌ను 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 గా ఎందుకు కనిపిస్తున్నాయి

ఆ ID కి సరిపోయే host ఖాతా ఏదీ లేనప్పుడు ls -l పేరుకు బదులుగా సంఖ్యాపరమైన 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

ఆ అవుట్‌పుట్ కంటైనర్ అంతర్నిర్మిత డిఫాల్ట్‌లతో రన్ అయిందని చెబుతోంది. ఊహించడం కంటే కంటైనర్ లోపలి నుండి దీన్ని నిర్ధారించుకోండి:

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 ఒక ఖాళీ 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 ప్రారంభంలో కేవలం మూడు మార్గాలను (paths) మాత్రమే /app, /config మరియు /defaults లతో chown చేస్తుంది. మీ మీడియా మౌంట్‌లు ఆ జాబితాలో ఉండవు. /data, /downloads మరియు /tv అప్లికేషన్‌కు ఎటువంటి మార్పులు లేకుండానే అందుతాయి. కాబట్టి, ఆ మౌంట్‌ల హోస్ట్ వైపున కంటైనర్ యూజర్‌కు రాయడానికి (write) అనుమతి లేని యాజమాన్యం (ownership) ఉంటే, కంటైనర్ సజావుగా ప్రారంభమవుతుంది, దాని బ్యానర్‌లో సరైన UIDని చూపిస్తుంది, కానీ మొదటి ఇంపోర్ట్ ప్రయత్నంలోనే విఫలమవుతుంది.

ఇది సరైన ప్రవర్తనే. ప్రతి కంటైనర్ ప్రారంభంలో పన్నెండు టెరాబైట్ల మీడియా లైబ్రరీపై రికర్సివ్‌గా chown చేయడం విపత్తుకు దారితీస్తుంది. దీని అర్థం మీడియా డైరెక్టరీల బాధ్యత మీదేనని, మరియు అనుమతుల సమస్యలు తలెత్తేది ఆ మౌంట్‌ల వద్దేనని గుర్తుంచుకోవాలి.

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

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 చెల్లుబాటు అవుతుంది మరియు ఫైల్ యాక్సెస్ సాధారణంగానే పనిచేస్తుంది. కేవలం పేరును గుర్తించడం (name lookup) మాత్రమే విఫలమవుతుంది.

Rootless Docker

Rootless Docker లో daemon మీ అన్‌ప్రివిలేజ్డ్ యూజర్‌గా రన్ అవుతుంది, కాబట్టి సర్వర్‌లో ఏదీ నిజమైన root గా రన్ అవ్వదు. ఇది ownership లెక్కలను పూర్తిగా మారుస్తుంది. కంటైనర్ 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 గా ఫైల్స్ రాస్తే, అవి 100999 పరిసరాల్లో ఉన్న సబార్డినేట్ IDకి చెందుతాయి, వీటిని మీ షెల్ తాకలేదు. కాబట్టి rootful daemon లో సరైన PUID విలువ ఇక్కడ తప్పు అవుతుంది. ఈ రెండు పద్ధతులు వేర్వేరు పొరలలో ఒకే సమస్యను పరిష్కరిస్తాయి, వీటిని సరిచూసుకోకుండా కలిపి వాడితే, మీరు ఒక డైరెక్టరీని తొలగించడానికి sudo అవసరమయ్యే పరిస్థితికి చేరుకుంటారు. మీరు rootless కి మారితే, లైబ్రరీని మైగ్రేట్ చేసే ముందు మీ సర్వర్‌పై ఒక ఫైల్ రాసి దాని ownership ను పరీక్షించండి.

ఒకే VPS పై నడిచే చాలా self-hosted స్టాక్‌లకు, rootful daemon పై PUID మరియు PGID వాడటమే ఆచరణాత్మకమైన ఎంపిక, ఎందుకంటే ఇమేజ్‌లు దీని కోసమే నిర్మించబడ్డాయి మరియు డాక్యుమెంట్ చేయబడ్డాయి. ఇమేజ్ README లో దీని కోసం పరీక్షించబడిందని ఉన్నప్పుడు, లేదా PUID సపోర్ట్ లేని అధికారిక అప్‌స్ట్రీమ్ ఇమేజ్‌ను వాడుతున్నప్పుడు user: కోసం ప్రయత్నించండి. ఒక VPS పై self-hosted AFFiNE instance వంటి డాక్యుమెంట్ వర్క్‌స్పేస్ చివరి కేటగిరీలోకి వస్తుంది, ఎందుకంటే దాని కంటైనర్‌లు ఏవీ PUID ని చదవవు మరియు దాని డేటాబేస్ డైరెక్టరీ, అప్‌లోడ్ చేసిన ఫైల్స్ యొక్క ownership ఎన్విరాన్‌మెంట్ బ్లాక్ ద్వారా కాకుండా రన్‌టైమ్ ద్వారా నిర్ణయించబడుతుంది.

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

ఒక Sonarr, Radarr మరియు డౌన్‌లోడ్ క్లయింట్‌తో కూడిన arr మీడియా స్టాక్ విషయంలో ఇది కేవలం సిద్ధాంతం మాత్రమే కాదు. డౌన్‌లోడ్ క్లయింట్ పూర్తి చేసిన ఫైల్‌ను /data/downloads లోకి రాస్తుంది. ఆ తర్వాత Sonarr ఆ ఫైల్‌ను /data/media లోకి hardlink చేస్తుంది లేదా తరలిస్తుంది. Hardlink పనిచేయాలంటే, రెండు కంటైనర్లకు ఒకే డైరెక్టరీ ట్రీపై write access ఉండాలి. ఒకవేళ డౌన్‌లోడ్ క్లయింట్ 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ని పంచుకుంటుంది.

ఆ తర్వాత స్టాక్‌లోని ప్రతి 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 తో ఆ ఫైల్‌ను తొలగించండి.

ఏ images ఏ variable ను ఉపయోగిస్తాయి

linuxserver.io images PUID, PGID మరియు UMASK లను ఉపయోగిస్తాయి. Paperless-ngx ఇదే భావన కోసం వేర్వేరు పేర్లను ఉపయోగిస్తుంది: USERMAP_UID మరియు USERMAP_GID, ఇవి రెండూ డిఫాల్ట్‌గా 1000 కి సెట్ చేయబడతాయి, మరియు వీటిని id -u మరియు id -g నుండి చదవమని దాని డాక్యుమెంటేషన్ సూచిస్తుంది. Photo servers కూడా ఇలాగే భిన్నంగా ఉంటాయి: PhotoPrism కు సొంతంగా PHOTOPRISM_UID మరియు PHOTOPRISM_GID జత ఉంది, అయితే Immich ఎటువంటి సమానమైన వేరియబుల్స్‌ను అందించదు మరియు container user ను Docker యొక్క user: కీకి వదిలేస్తుంది, కాబట్టి PhotoPrism మరియు Immich మధ్య ఎంపిక అనేది మీ సర్వర్‌లోని అతిపెద్ద లైబ్రరీ కోసం మీరు ఏ మెకానిజంను నిర్వహించాలో కూడా నిర్ణయిస్తుంది. సాధారణ database మరియు web server images తో సహా అనేక అధికారిక upstream images, ఒక స్థిరమైన built-in user తో వస్తాయి మరియు మీరు user: ను ఉపయోగించాలని లేదా దానిని అలాగే వదిలేయాలని ఆశిస్తాయి. మీరు తర్వాత జోడించే infrastructure కు కూడా ఇదే వర్తిస్తుంది, కాబట్టి ఒకే login కోసం మీ apps ముందు Authentik ను ఉంచడం అంటే PUID ను అస్సలు చదవని అధికారిక server, Postgres మరియు Redis images ను రన్ చేయడం, మరియు వాటి volume ownership మీరు కాన్ఫిగర్ చేయగల entrypoint నుండి కాకుండా runtime నుండి వస్తుంది.

కాబట్టి ప్రాజెక్ట్‌ల మధ్య environment block ను కాపీ చేసే ముందు ప్రతి image యొక్క README ను తనిఖీ చేయండి. మీరు సెట్ చేసిన ఏదైనా environment variable ను Docker ఏ container లోకైనా పంపుతుంది, లోపల ఏదైనా దానిని చదువుతుందా లేదా అనే సంబంధం లేకుండా; ఏదీ ఉపయోగించని PUID ఎటువంటి error ను లేదా warning ను ఇవ్వదు మరియు ఎటువంటి ప్రభావాన్ని చూపదు. ఆ container దాని Dockerfile చివరలో ఏ user తో ముగిస్తే ఆ user గానే రన్ అవుతుంది, మరియు అది రాసే ఫైళ్ల ownership ద్వారా మీరు దానిని తెలుసుకోవచ్చు.

FAQ

నా Docker ఫైల్స్ ఎందుకు 911:911 యాజమాన్యంలో ఉన్నాయి?

911 అనేది linuxserver.io ఇమేజ్‌లలో నిర్మించబడిన abc యూజర్ యొక్క UID మరియు GID. ఇది కనిపిస్తుందంటే, కంటైనర్ PUID మరియు PGID సెట్ చేయకుండానే ప్రారంభమైందని అర్థం, కాబట్టి దాని init స్క్రిప్ట్ డిఫాల్ట్ విలువలను అలాగే ఉంచింది. మీ హోస్ట్ మెషీన్‌లో 911 ID కలిగిన అకౌంట్ ఏదీ లేనందున, చూపించడానికి పేరు లేక ls -l ఆ సంఖ్యలను నేరుగా చూపిస్తుంది. id యొక్క అవుట్‌పుట్‌ను PUID మరియు PGID కి సెట్ చేయండి, 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 ఉపయోగించండి, ఎందుకంటే ఎంట్రీపాయింట్ /config ని సరిచేయడానికి మరియు దాని సొంత సేవలను సరిగ్గా ప్రారంభించడానికి తగినంత సమయం root గానే రన్ అవుతుంది. ఇమేజ్‌కు PUID సపోర్ట్ లేనప్పుడు లేదా నాన్-రూట్ ఆపరేషన్ కోసం టెస్ట్ చేయబడిందని ఇమేజ్ 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 బిట్‌ను సెట్ చేయండి.