Docker Compose-ல் PUID மற்றும் PGID என்றால் என்ன?

PUID மற்றும் PGID என்றால் என்ன

PUID மற்றும் PGID என்பவை சில container images தொடங்கும் போது வாசிக்கும் இரண்டு environment variables ஆகும். Docker இவற்றை ஒருபோதும் கவனிப்பதில்லை. இவை linuxserver.io images மற்றும் சில குறிப்பிட்ட images-ல் பயன்படுத்தப்படும் ஒரு மரபு (convention). எனவே, இவற்றை வாசிக்கும்படி எழுதப்படாத ஒரு image, இந்த variables-ஐ அமைதியாகப் புறக்கணித்துவிடும்.

ஒரு linuxserver.io image-க்குள் abc என்ற பயனர் உள்ளார். இது build செய்யப்படும்போது 911 என்ற UID (user ID) மற்றும் GID (group ID) உடன் உருவாக்கப்படுகிறது. இந்த container root பயனர் உரிமையுடன் தொடங்குகிறது, அதன் init scripts-ஐ இயக்குகிறது. அந்த scripts-ல் ஒன்று, மற்றவை நடப்பதற்கு முன்பே அந்தப் பயனரின் எண்ணை மாற்றுகிறது:

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

-o flag, ஏற்கனவே பயன்பாட்டில் உள்ள ஒரு ID-ஐப் பயன்படுத்த அனுமதிக்கிறது. அதன் பிறகு, init செயல்முறை தனது அதிகாரத்தைக் குறைத்துக்கொண்டு, abc என்ற பயனராக application-ஐ இயக்குகிறது. எனவே, PUID=1000 Docker-ஐ ஒருபோதும் சென்றடைவதில்லை. இந்த variable, application தொடங்குவதற்கு முன்பே container-க்குள் இருக்கும் ஒரு பயனரின் எண்ணை மாற்றுகிறது. இதன் பொருள், அந்த application எழுதும் ஒவ்வொரு கோப்பும் உங்கள் வட்டில் 1000 என்ற உரிமையாளருடன் சேமிக்கப்படும் என்பதாகும். PUID-ஐ அமைக்காமல் விட்டால், abc 911 என்ற எண்ணையே வைத்திருக்கும். இதனால்தான், சரியாக உள்ளமைக்கப்படாத bind mount-ல் உருவாகும் கோப்புகள் 911:911 என்ற உரிமையாளரைக் கொண்டிருக்கின்றன.

id மூலம் உங்கள் இரண்டு எண்களைப் பெறுதல்

தரவு அடைவுகளை (data directories) வைத்திருக்கும் பயனராக, host-ல் இதை இயக்கவும்:

id

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

uid என்பது உங்கள் PUID மற்றும் gid என்பது உங்கள் PGID ஆகும். ஒரு script-க்கு, id -u மற்றும் id -g ஆகியவை வெறும் எண்களை மட்டும் அச்சிடும். பெரும்பாலான புதிய VPS images-ல் முதல் பயனர் கணக்கு 1000:1000 என்று இருக்கும், ஆனால் அதை அப்படியே எடுத்துக்கொள்ள வேண்டாம். மீண்டும் கட்டமைக்கப்பட்ட server அல்லது பின்னர் சேர்க்கப்பட்ட இரண்டாவது கணக்கு 1001 அல்லது அதற்கு மேற்பட்ட எண்ணைக் கொண்டிருக்கும், இங்கே தவறான எண்ணைப் பயன்படுத்துவது முழு பிழைக்கும் காரணமாகும். உங்கள் சேவைகள் உங்கள் சொந்த login பயனருக்குப் பதிலாக ஒரு பிரத்யேக சேவை கணக்கின் (dedicated service account) கீழ் இயங்கினால், id thatuser என்பதை இயக்கி அங்கிருந்து எண்களைப் பெறவும்.

உங்கள் கோப்புகள் ஏன் 911:911 என்று காட்டுகின்றன

அந்த ID-க்கு இணையான host account எதுவும் இல்லாதபோது, ls -l ஒரு பெயருக்குப் பதிலாக எண்ணை அச்சிடுகிறது. உங்கள் server-ல் எந்தவொரு கோப்பும் 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 அதன் முடிவை startup log-ல் இரண்டு வரிகளாக அச்சிடுகிறது:

User UID:    911
User GID:    911

உங்கள் Compose கோப்பில் PUID=1000-ஐ அமைத்த பிறகும் அந்த வரிகள் 911 என்று காட்டினால், அந்த variable container-ஐச் சென்றடையவில்லை என்று அர்த்தம். பொதுவாக, நீங்கள் docker-compose.yml-ஐத் திருத்திவிட்டு, docker compose restart-ஐ இயக்கியதே இதற்குக் காரணம்; இது ஏற்கனவே உள்ள container-ஐ அதன் பழைய environment-உடன் மீண்டும் பயன்படுத்துகிறது. Environment மாற்றங்களுக்கு docker compose up -d தேவை, இதுவே container-ஐ மீண்டும் உருவாக்கும்.

container உருவாக்கிய கோப்பை உங்களால் ஏன் நீக்க முடியவில்லை

Kernel கோப்புகளின் பெயர்களை ஒப்பிடுவதில்லை, எண்களை மட்டுமே ஒப்பிடும். உங்கள் shell UID 1000-ஆக இயங்குகிறது. அந்த கோப்பு UID 911-க்கு சொந்தமானது. அதை உள்ளடக்கிய directory drwxr-xr-x என்பதும் 911-க்கு சொந்தமானது, எனவே group மற்றும் பிற பயனர்களுக்கு read மற்றும் execute அனுமதி மட்டுமே உண்டு, write அனுமதி இல்லை. ஒரு கோப்பை நீக்க, அந்த கோப்பின் மீது அல்ல, அதன் directory மீது write அனுமதி தேவை. எனவே, கோப்பு பார்ப்பதற்கு பாதிப்பில்லாதது போலத் தெரிந்தாலும், உங்களுக்கு இந்த பிழை வரும்:

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

ஒரு container கோப்பை எழுத முயலும்போது, இதே சிக்கல் மறுபக்கத்தில் நிகழ்கிறது. Host directory உங்கள் பயனருக்கு சொந்தமாக இருந்து, mode 755-ல் இருந்தால், application 911-ஆக இயங்கும்போது, அதன் முதல் write முயற்சி Permission denied பிழையுடன் தோல்வியடையும். அந்த application தனது சொந்த மொழியில் இதைத் தெரிவிக்கும். Sonarr அல்லது Radarr போன்ற .NET application-களில் இது UnauthorizedAccessException: Access to the path '/data/downloads' is denied என்று காட்டப்படும். கோப்பிற்கு முன்னால் உள்ள permission string, நீங்கள் எந்த மூன்று permission தொகுப்புகளால் கட்டுப்படுத்தப்படுகிறீர்கள் என்பதைத் தெரிவிக்கும். drwxr-xr-x என்பதைச் சரியாக வாசிப்பது எப்படி என்பதைத் தெரிந்துகொண்டால், இந்த பிழை ஏன் ஏற்படுகிறது என்பது தெளிவாகிவிடும்.

இது குறிப்பாக ஒரு bind mount சிக்கலாகும். Docker ஒரு empty named volume-ஐ உருவாக்கி, அதை image-ல் உள்ள ஒரு path-ன் மீது mount செய்யும்போது, அது அந்த path-ல் உள்ள உள்ளடக்கங்களை, ownership மற்றும் permission bits-உடன் சேர்த்து volume-க்குள் நகலெடுக்கும். இதனால் application தனக்குச் சொந்தமான directory-யைக் கண்டறியும். Bind mount-க்கு இந்த வசதி கிடையாது: Docker உங்கள் host directory-யை அப்படியே mount செய்யும். இந்த வேறுபாடுதான் எப்போது bind mount-ஐப் பயன்படுத்த வேண்டும், எப்போது named volume-ஐப் பயன்படுத்த வேண்டும் என்பதைத் தெரிந்துகொள்வதற்கான நடைமுறை காரணங்களில் ஒன்றாகும்.

ஏற்கனவே தவறாக உள்ள ஒரு directory-ஐ சரிசெய்தல்

PUID மற்றும் PGID-ஐ அமைப்பது, அந்த application இனிமேல் செயல்படும் விதத்தை மட்டுமே மாற்றும். இது வட்டில் (disk) ஏற்கனவே உள்ள கோப்புகளைப் பின்னோக்கிச் சென்று சரிசெய்யாது. Stack-ஐ நிறுத்திவிட்டு, 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-ஐப் பயன்படுத்தவும். Container நிறுத்தப்பட்ட நிலையில் இதைச் செய்யவும். ஏனெனில், இயங்கிக்கொண்டிருக்கும் ஒரு application, recursive chown செயல்பாட்டின் போது கோப்புகளை எழுதிக்கொண்டிருந்தால், அது பாதியளவு மட்டுமே சரிசெய்யப்பட்ட directory tree-ஐ உருவாக்கி, குழப்பமான பிழைகளை மீண்டும் ஏற்படுத்தக்கூடும்.

PUID மற்றும் PGID சரிசெய்யாதவை

எல்லாம் சரியாகச் செய்தும் சிக்கலில் சிக்கும் பயனர்களுக்கான பகுதி இது. linuxserver init தொடங்கும் போது சரியாக மூன்று பாதைகளை மட்டுமே /app, /config மற்றும் /defaults ஆகியவற்றை chown செய்கிறது. உங்கள் media mounts அந்தப் பட்டியலில் இல்லை. /data, /downloads மற்றும் /tv ஆகியவை மாற்றப்படாமல் அப்படியே application-க்கு வழங்கப்படுகின்றன. எனவே, அந்த mounts-ன் host பக்கத்தில் உள்ள உரிமையை container பயனர் எழுத முடியாதபடி இருந்தால், container சரியாகத் தொடங்கும், அதன் banner-ல் சரியான UID-ஐக் காட்டும், ஆனால் முதல் import-ன் போது தோல்வியடையும்.

இது சரியான செயல்பாடே. ஒவ்வொரு முறை container தொடங்கும் போதும் பன்னிரண்டு terabyte media library முழுவதும் recursive chown செய்வது பேரழிவாக முடியும். இதன் பொருள் media directories-ஐ நிர்வகிப்பது உங்கள் பொறுப்பு என்பதாகும்; அங்கேதான் அனுமதிகள் (permissions) தவறாகப் போக வாய்ப்புள்ளது. இத்தகைய தோல்வி, container ஆரோக்கியமாகத் தெரிந்த சில மணிநேரங்களுக்குப் பிறகு application log-ல் மெதுவாகவே வெளிப்படும் என்பதால், உங்கள் சொந்த VPS-ல் ntfy-ஐ அமைத்து, உங்கள் தொலைபேசிக்கு எச்சரிக்கைகளை அனுப்புவது ஒரு வார காலத் தரவு இழப்பைத் தவிர்க்கும் எளிய வழியாகும்.

பயனரைக் கட்டுப்படுத்துவதற்கான மூன்று வழிகள் மற்றும் அவை ஒவ்வொன்றும் பொருந்தும் சூழல்கள்

PUID மற்றும் PGID environment variables

இந்த முறை, அதன் entrypoint-ல் இந்த மாறிகளை வாசிக்கும் images-க்கு மட்டுமே வேலை செய்யும். இது மிகவும் பிரபலமானது, ஏனெனில் container முதலில் root-ஆகவே தொடங்கும், தனது சொந்த அமைப்புகளை முடிக்கும், /config-ஐ சரிசெய்யும், அதன் பிறகுதான் சலுகைகளைக் குறைக்கும் (drops privileges). Docker Mods மற்றும் custom init scripts தொடர்ந்து வேலை செய்யும். இதன் குறைபாடு என்னவென்றால், நீங்கள் ஒரு platform வசதியை விட ஒரு மரபையே (convention) நம்புகிறீர்கள், மேலும் இந்த மாறிப் பெயர்கள் அனைத்து திட்டங்களிலும் ஒரே மாதிரியாக இருப்பதில்லை.

Compose-ல் உள்ள user: key

இது ஒரு உண்மையான Docker வசதியாகும். இது அனைத்து images-லும் வேலை செய்யும், ஏனெனில் image-ன் சொந்த code இயங்குவதற்கு முன்பே container runtime இதைச் செயல்படுத்திவிடும்:

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

இந்த process ஒரு நொடி கூட root-ஆக இயங்காது, இது ஒரு உண்மையான பாதுகாப்பு மேம்பாடு ஆகும். அதே சமயம், entrypoint-ல் root தேவைப்படும் எதையும் இது செயலிழக்கச் செய்யும். linuxserver images-ல், அவர்கள் சோதித்த images-க்கு மட்டுமே இதை ஆதரிக்கிறார்கள். இதன் நிபந்தனைகள் தெளிவானவை: PUID மற்றும் PGID எந்த விளைவையும் ஏற்படுத்தாது, Docker Mods இயங்காது, custom services இயங்காது, மேலும் mounted volume-களின் அனுமதிகளுக்கு (permissions) நீங்களே பொறுப்பாவீர்கள். அவர்களின் ஆவணப்படுத்தப்பட்ட முறையில், இந்த flag-உடன் writable /run-ஐப் பயன்படுத்துவார்கள்:

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

ஒரு சிறிய cosmetic பக்கவிளைவு பயனர்களை ஆச்சரியப்படுத்தலாம். ஒரு numeric user:-க்கு container-ன் /etc/passwd-ல் எந்தப் பதிவும் இருக்காது, எனவே உள்ளே இருக்கும் கருவிகள் whoami: cannot find name for user ID 1000 என்று காட்டும். அந்த ID செல்லுபடியாகும் மற்றும் கோப்புகளை அணுகுவது சாதாரணமாக நடக்கும். பெயர் தேடல் (name lookup) மட்டுமே தோல்வியடையும்.

Rootless Docker

Rootless Docker, daemon-ஐ உங்கள் unprivileged பயனராகவே இயக்குகிறது, எனவே server-ல் எதுவும் உண்மையான root-ஆக இயங்காது. இது ownership கணக்கீட்டை முழுமையாக மாற்றுகிறது. Container UID 0, rootless Docker-ஐ இயக்கும் பயனரின் host UID-ஆக மாறுகிறது. Container UID n (1 அல்லது அதற்கு மேற்பட்ட n-க்கு) subuid + (n - 1)-ஆக மாறுகிறது. இதில் subuid என்பது /etc/subuid மற்றும் /etc/subgid-ல் உங்களுக்கு ஒதுக்கப்பட்ட வரம்பின் தொடக்கமாகும். Docker அங்கு குறைந்தது 65,536 subordinate ID-களை எதிர்பார்க்கிறது.

இந்த mapping-ஐ மீண்டும் கவனமாகப் படியுங்கள், ஏனெனில் இது வழக்கமான ஆலோசனையைத் தலைகீழாக மாற்றுகிறது. Rootless Docker-ல், root-ஆக எழுதும் ஒரு container, உங்களுடைய ownership-ல் உள்ள கோப்புகளை உருவாக்குகிறது. UID 1000-ஆக எழுதும் ஒரு container, 100999-க்கு அருகில் உள்ள ஒரு subordinate ID-ல் கோப்புகளை உருவாக்குகிறது, அதை உங்கள் shell-ஆல் அணுக முடியாது. எனவே, rootful daemon-ல் சரியாக இருக்கும் PUID மதிப்பு, இங்கே தவறானதாக இருக்கும். இந்த இரண்டு வழிமுறைகளும் வெவ்வேறு அடுக்குகளில் ஒரே சிக்கலைத் தீர்க்கின்றன. அவற்றைச் சரிபார்க்காமல் ஒன்றன் மேல் ஒன்றாகப் பயன்படுத்தினால், அதை நீக்க நீங்கள் sudo-ஐப் பயன்படுத்த வேண்டியிருக்கும். நீங்கள் rootless முறைக்கு மாறினால், ஒரு library-ஐ இடம்பெயர்த்துவதற்கு முன், உங்கள் server-ல் எழுதப்பட்ட ஒரு கோப்பின் ownership-ஐச் சோதித்துப் பாருங்கள்.

ஒரே VPS-ல் இயங்கும் பெரும்பாலான self-hosted stacks-க்கு, rootful daemon-ல் PUID மற்றும் PGID-ஐப் பயன்படுத்துவதே நடைமுறைக்குச் சிறந்த தேர்வாகும், ஏனெனில் images அதற்காகவே உருவாக்கப்பட்டு ஆவணப்படுத்தப்பட்டுள்ளன. ஒரு image README-ல் அது சோதிக்கப்பட்டதாகக் குறிப்பிட்டிருந்தால் அல்லது PUID ஆதரவே இல்லாத ஒரு official upstream image-ஐ நீங்கள் பயன்படுத்தினால் மட்டும் user:-ஐப் பயன்படுத்துங்கள். ஒரே VPS-ல் உள்ள self-hosted AFFiNE instance போன்ற ஒரு ஆவண workspace இந்த கடைசி வகையைச் சார்ந்தது, ஏனெனில் அதன் containers எதிலும் PUID-ஐ வாசிப்பதில்லை. அதன் database directory மற்றும் பதிவேற்றப்பட்ட கோப்புகளின் ownership, environment block-ல் உள்ள எதையும் விட runtime-ஆலேயே தீர்மானிக்கப்படுகிறது. self-hosted Chatwoot support desk-க்கும் இதுவே பொருந்தும்; அங்குள்ள Rails container மற்றும் அதன் Sidekiq worker ஆகிய இரண்டும் ஒரே uploads directory-ல் எழுதுகின்றன, ஆனால் அவை PUID-ஐ வாசிப்பதில்லை. எனவே, அந்த directory அந்த image இயல்பாக எந்தப் பயனராக இயங்குகிறதோ, அந்த ownership-ஐக் கொண்டிருக்க வேண்டும். புதிய stack-களுக்கும் இது மாறாது, எனவே குழுவில் உள்ள ஒவ்வொருவருக்கும் தனித்தனி sandboxed OneCLI agent வழங்குவது, அந்தந்த workspace directories மற்றும் Postgres data directory-ஐ அந்தந்த image இயல்பாக இயங்கும் பயனரின் ownership-லேயே வைத்திருக்கும். இது PUID சிக்கல் அல்ல, மாறாக ஒரு user: மற்றும் chown சிக்கலாகும். Codex, Claude Code மற்றும் Hermes-க்கு முன்னால் ஒரே ஒரு self-hosted API-ஐ வைக்கும்போதும் இதே நிலைதான், ஏனெனில் அந்த image அதன் சொந்த built-in பயனராகவே இயங்குகிறது மற்றும் அதன் database மற்றும் keys-ஐக் கொண்ட bind mount அந்தப் பயனர் கொண்டுள்ள ownership-ஐயே ஏற்கும்.

மீடியா ஸ்டாக் (media stack) சூழல்: கொள்கலன்களுக்கு இடையே பகிரப்பட்ட ஒரு குழு

ஒரு Sonarr, Radarr மற்றும் download client கொண்ட arr media stack என்பது இந்த கோட்பாடு நடைமுறைக்கு வரும் இடமாகும். Download client ஒரு கோப்பை முடித்தவுடன் அதை /data/downloads-ல் எழுதும். அதன் பிறகு Sonarr அந்த கோப்பை /data/media-க்கு hardlink செய்யும் அல்லது நகர்த்தும். Hardlink சரியாகச் செயல்பட, இரண்டு கொள்கலன்களுக்கும் (containers) ஒரே கோப்பக அமைப்பில் எழுதும் உரிமை (write access) இருக்க வேண்டும். Download client 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 மூலம் சேர்க்கப்பட்ட குழு, ஏற்கனவே திறந்திருக்கும் shell session-ல் உடனடியாகத் தெரியாது.

கொள்கலனுக்குள், groupmod -o -g 13000 abc என்பது abc குழுவை 13000 என மறுஎண் இடுகிறது. இதனால் abc உங்கள் host media குழுவின் அதே GID-உடன் கோப்புகளை எழுதும். ஸ்டாக்கில் உள்ள ஒவ்வொரு கொள்கலனும் அதன் சொந்த PUID-ஐ வைத்திருக்கும், ஆனால் அந்த ஒரே PGID-ஐப் பகிர்ந்து கொள்ளும். இதில் Jellyfin போன்ற, முடிக்கப்பட்ட நூலகத்தை வாசிக்கும் கொள்கலன்களும், அதன் மேல் இணைக்கப்படும் 90-களின் வீடியோ கடை போல நூலகத்தைக் காட்டும் Halcyon போன்ற front-end-களும் அடங்கும்.

பிறகு, ஸ்டாக்கில் உள்ள ஒவ்வொரு linuxserver கொள்கலனிலும் UMASK=002-ஐ அமைக்கவும். இதுவே பலரும் தவறவிடும் படிநிலை. இந்த images-ல் இயல்பாக UMASK=022 இருக்கும், இது புதிய கோப்புகளிலிருந்து group write பிட்டை நீக்கிவிடும். இதனால் கோப்புகள் 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} பாணி மாற்றீட்டிற்காகத் தானாகவே வாசிக்கும். இதுவே நீங்கள் நற்சான்றிதழ்களுக்குப் (credentials) பயன்படுத்தும் அதே நுட்பமாகும். மதிப்புகளை docker-compose.yml-ல் வைக்காமல் .env கோப்பில் வைத்திருக்கும் பழக்கம் இதற்கும் பொருந்தும், ஆனால் இந்த இரண்டு எண்களும் ரகசியமானவை அல்ல.

அமைப்பை நம்புவதற்குப் பதிலாக, முழுமையாகச் சரிபார்க்கவும். ஒரு கொள்கலனுக்குள் இருந்து ஒரு கோப்பை உருவாக்கி, அதை host-லிருந்து வாசிக்கவும்:

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

சரியான முடிவில் உங்கள் PUID உரிமையாளராகவும், 13000 குழுவாகவும், -rw-rw-r-- பயன்முறையாகவும் (mode) இருக்க வேண்டும். குழுவின் பயன்முறை 1000 என்று இருந்தால், அந்த கோப்பகத்தில் setgid பிட் விடுபட்டுள்ளது என்று அர்த்தம். பயன்முறை -rw-r--r-- என்று இருந்தால், UMASK மாறி (variable) செயல்படவில்லை என்று அர்த்தம். கொள்கலனை restart செய்யாமல், மீண்டும் உருவாக்கியுள்ளீர்களா என்பதைச் சரிபார்க்கவும். சோதனையை முடித்த பிறகு 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: key-க்கு விட்டுவிடுகிறது. எனவே, PhotoPrism மற்றும் Immich-க்கு இடையே தேர்ந்தெடுப்பது என்பது, உங்கள் server-ல் உள்ள மிகப்பெரிய library-க்கு எந்த வகையான நிர்வாக முறையை நீங்கள் கையாளப் போகிறீர்கள் என்பதையும் தீர்மானிக்கிறது. பொதுவான database மற்றும் web server images உட்பட பல அதிகாரப்பூர்வ upstream images-கள், ஏற்கனவே உள்ள ஒரு fixed user-ஐயே பயன்படுத்துகின்றன. நீங்கள் user:-ஐப் பயன்படுத்த வேண்டும் அல்லது அதை மாற்றாமல் அப்படியே விட்டுவிட வேண்டும் என்று அவை எதிர்பார்க்கின்றன. சிறிய single-app deployments-களிலும் இதே கேள்வி எழுகிறது. எனவே, நீங்கள் self-hosted openGym workout tracker-ஐ நிறுவும்போது, bind mount-ஐ அதற்குச் சுட்டிக்காட்டுவதற்கு முன்பாக, அந்த container எந்த user-ஆக இயங்குகிறது என்பதைச் சரிபார்ப்பது அவசியம். ஏனெனில், அதன் database-ஐக் கொண்டிருக்கும் directory, நீங்கள் PUID-ஐ அமைத்தாலும் இல்லாவிட்டாலும் அந்த user-ன் உரிமையையே (ownership) பெறும். Remote access relay-ம் இதே வகையைச் சார்ந்தது. எனவே, நீங்கள் சொந்தமாக RustDesk relay server-ஐ இயக்கும்போது, முதல்முறை தொடங்கும்போதே hbbs உருவாக்கும் Ed25519 key pair, அந்த image எந்த user-ஆக முடிகிறதோ அந்த user-ன் உரிமையிலேயே உங்கள் bind mount-ல் அமையும். அதைச் சரிசெய்ய host side-ல் chown-ஐப் பயன்படுத்துவது மட்டுமே ஒரே வழி. நீங்கள் பிற்காலத்தில் சேர்க்கும் infrastructure-க்கும் இது பொருந்தும். Authentik-ஐ உங்கள் apps-க்கு முன்னால் ஒற்றை login-க்காக வைப்பது என்பது, PUID-ஐ வாசிக்காத அதிகாரப்பூர்வ server, Postgres மற்றும் Redis images-களை இயக்குவதைக் குறிக்கும். இவற்றின் volume ownership, நீங்கள் configure செய்யக்கூடிய entrypoint-லிருந்து வராமல், runtime-லிருந்து வரும்.

எனவே, ஒரு environment block-ஐ ஒரு project-லிருந்து மற்றொன்றுக்கு நகலெடுக்கும் முன், ஒவ்வொரு image-ன் README-ஐயும் சரிபார்க்கவும். நீங்கள் அமைக்கும் எந்தவொரு environment variable-ஐயும் Docker அந்த container-க்குள் அனுப்பிவிடும்; உள்ளே இருக்கும் ஏதேனும் ஒரு மென்பொருள் அதை வாசிக்கிறதா இல்லையா என்பது அதற்குத் தெரியாது. எதையும் பயன்படுத்தாத ஒரு PUID, எந்தப் பிழையையோ அல்லது எச்சரிக்கையையோ தராது, எந்த விளைவையும் ஏற்படுத்தாது. அந்த container அதன் Dockerfile எதில் முடிகிறதோ அந்த user-ஆகவே இயங்கும். அது உருவாக்கும் கோப்புகளின் உரிமையைப் (ownership) பார்த்தே நீங்கள் அதைத் தெரிந்துகொள்ள முடியும். self-hosted open-kritt security scanning stack உட்பட, எதைப் புதிதாகச் சேர்த்தாலும், அதற்கு முன்பே இந்த வாசிப்பைச் செய்யுங்கள். அந்த images PUID-ஐ மதிக்கின்றனவா அல்லது நீங்கள் mount செய்யும் directory-களின் ownership அந்த images-களாலேயே தீர்மானிக்கப்படுகிறதா என்பதை அதன் Compose file உங்களுக்குத் தெரிவிக்கும்.

FAQ

எனது Docker கோப்புகள் ஏன் 911:911 உரிமையில் உள்ளன?

911 என்பது linuxserver.io images-ல் உள்ள abc பயனரின் UID மற்றும் GID ஆகும். இது காட்டப்பட்டால், PUID மற்றும் PGID ஆகியவற்றை அமைக்காமல் container தொடங்கப்பட்டுள்ளது என்று அர்த்தம்; எனவே அதன் init script இயல்பான அமைப்புகளை அப்படியே விட்டுவிட்டது. உங்கள் host-ல் 911 என்ற ID கொண்ட கணக்கு இல்லாததால், ls -l அந்த raw எண்களைக் காட்டுகிறது. id-ன் வெளியீட்டை PUID மற்றும் PGID-ல் அமைக்கவும், docker compose up -d மூலம் container-ஐ மீண்டும் உருவாக்கவும், பின்னர் பாதிக்கப்பட்ட கோப்பகத்தில் sudo chown -R 1000:1000 மூலம் கோப்புகளின் உரிமையைச் சரிசெய்யவும்.

PUID மற்றும் PGID அனைத்து Docker images-லும் வேலை செய்யுமா?

இல்லை. இவை Docker-ன் அம்சம் அல்ல, Docker இவற்றை வாசிப்பதில்லை. இவை அந்தந்த image-ன் entrypoint-ல் PUID/PGID-ஐ வாசித்து, application-ஐத் தொடங்கும் முன் usermod மற்றும் groupmod-ஐ அழைக்கும் images-ல் மட்டுமே வேலை செய்யும். இது linuxserver.io குடும்பம் மற்றும் இந்த முறையைப் பின்பற்றும் சில திட்டங்களுக்கு மட்டுமே பொருந்தும். பிற திட்டங்கள், paperless-ngx-ல் உள்ள USERMAP_UID மற்றும் USERMAP_GID போன்ற வெவ்வேறு பெயர்களைப் பயன்படுத்துகின்றன. இவற்றை ஆதரிக்காத image-ல், இந்த variables ஏற்றுக்கொள்ளப்படும், ஆனால் எந்த எச்சரிக்கையும் இன்றி புறக்கணிக்கப்படும்.

நான் PUID மற்றும் PGID-ஐப் பயன்படுத்த வேண்டுமா அல்லது Docker Compose-ல் user: key-ஐப் பயன்படுத்த வேண்டுமா?

image அவற்றை ஆதரிக்கும்போது PUID மற்றும் PGID-ஐப் பயன்படுத்தவும். ஏனெனில், entrypoint root-ஆக இயங்கி /config-ஐச் சரிசெய்து, அதன் சேவைகளைச் சரியாகத் தொடங்கும். image-ல் PUID ஆதரவு இல்லையென்றால் அல்லது அது non-root செயல்பாட்டிற்குச் சோதிக்கப்பட்டது என்று README-ல் குறிப்பிடப்பட்டிருந்தால் user:-ஐப் பயன்படுத்தவும். linuxserver image-ல் user:-ஐ அமைத்தால், PUID மற்றும் PGID செயலிழந்துவிடும், Docker Mods மற்றும் custom services இயங்காது, மேலும் அனைத்து mounted volume-களின் அனுமதிகளையும் நீங்களே நிர்வகிக்க வேண்டியிருக்கும்.

Sonarr-ல் சரியான PUID இருந்தும் கோப்புகளை நகர்த்த முடியவில்லை. என்ன தவறு?

மூன்று விஷயங்களை வரிசையாகச் சரிபார்க்கவும். முதலாவதாக, media mount: init script /app, /config மற்றும் /defaults-ஐ மட்டுமே chown செய்யும், எனவே /data அல்லது /downloads ஆகியவை host-ல் உள்ள உரிமையையே கொண்டிருக்கும். இரண்டாவதாக, shared group: download client மற்றும் Sonarr வெவ்வேறு GID-களில் இயங்கினால், ஒன்றின் கோப்புகளை மற்றொன்றால் மாற்ற முடியாது, எனவே stack-ல் உள்ள அனைத்து container-களுக்கும் ஒரே PGID-ஐ வழங்கவும். மூன்றாவதாக, umask: image-ன் இயல்பான UMASK=022 கோப்புகளை 0644 என்ற அனுமதியுடன் எழுதும், இதில் group write bit இருக்காது, இது shared group-ன் நோக்கத்தையே சிதைக்கும். UMASK=002-ஐ அமைக்கவும், புதிய கோப்புகள் group-ஐப் பெற, கோப்பகங்களில் chmod 2775 மூலம் setgid bit-ஐ அமைக்கவும்.