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

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

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

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

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

-o flag, ஏற்கனவே பயன்பாட்டில் உள்ள ஒரு ID-ஐப் பயன்படுத்த அனுமதிக்கிறது. அதன் பிறகு, init செயல்முறை தனது அதிகாரங்களைக் குறைத்துக்கொண்டு, abc என்ற பயனராக application-ஐ இயக்கும். எனவே, PUID=1000 என்பது Docker-க்கு ஒருபோதும் தெரிவதில்லை. இந்த variable, application தொடங்குவதற்கு முன்பே container-க்குள் இருக்கும் ஒரு பயனரின் ID-ஐ மாற்றுகிறது. இதன் பொருள், அந்த 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 பயனருக்குப் பதிலாக ஒரு பிரத்யேக சேவை கணக்கின் கீழ் இயங்கினால், id thatuser என்பதை இயக்கி அங்கிருந்து எண்களைப் பெறவும்.

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

அந்த ID-க்கு இணையான host account எதுவும் இல்லாதபோது, ls -l பெயருக்குப் பதிலாக numeric ID-ஐக் காட்டுகிறது. உங்கள் 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 அதன் உள்ளமைக்கப்பட்ட defaults-உடன் இயங்கியதாகக் கூறுகிறது. ஊகிப்பதற்குப் பதிலாக, container-க்குள் இருந்து இதை உறுதிப்படுத்தவும்:

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

linuxserver init அதன் முடிவை startup log-ல் இரண்டு வரிகளாக அச்சிடுகிறது:

User UID:    911
User GID:    911

உங்கள் Compose file-ல் 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-க்கு சொந்தமானது. அதை உள்ளடக்கிய கோப்பகம் drwxr-xr-x ஆகும், இதுவும் 911-க்கு சொந்தமானது. எனவே, group மற்றும் other ஆகியவற்றுக்கு read மற்றும் execute அனுமதி மட்டுமே உண்டு, write அனுமதி இல்லை. ஒரு கோப்பை நீக்க, அந்த கோப்பின் மீது அல்ல, அதன் கோப்பகத்தின் (directory) மீது write அனுமதி தேவை. எனவே, கோப்பு பார்ப்பதற்கு பாதிப்பில்லாததாகத் தெரிந்தாலும், உங்களுக்கு இந்த பிழை ஏற்படுகிறது:

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

ஒரு container எழுதும்போதும் இதே சிக்கல் மறுபக்கத்தில் ஏற்படுகிறது. host கோப்பகம் உங்கள் பயனருக்கு சொந்தமாக இருந்து, 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 ஒரு வெற்று named volume-ஐ உருவாக்கி, அதை image-ல் உள்ள ஒரு path-ன் மீது mount செய்யும்போது, அது அந்த path-ல் உள்ள உள்ளடக்கங்களை, ownership மற்றும் permission bits-உடன் சேர்த்து volume-க்குள் நகலெடுக்கும். இதனால் application தனக்குச் சொந்தமான கோப்பகத்தைக் கண்டறியும். ஆனால் bind mount-க்கு இந்த வசதி கிடையாது: Docker உங்கள் host கோப்பகத்தை அப்படியே mount செய்கிறது. இந்த வேறுபாடுதான் bind mount எப்போது named volume-ஐ விடச் சிறந்தது மற்றும் எப்போது இல்லை என்பதைத் தெரிந்துகொள்வதற்கான நடைமுறை காரணங்களில் ஒன்றாகும்.

ஏற்கனவே தவறாக உள்ள கோப்பகத்தைச் சரிசெய்தல்

PUID மற்றும் PGID-ஐ அமைப்பது, இனிவரும் காலங்களில் அந்த application செயல்படும் விதத்தை மட்டுமே மாற்றும். இது வட்டில் ஏற்கனவே உள்ள கோப்புகளைப் பின்னோக்கிச் சென்று சரிசெய்யாது. 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 செயல்பாட்டின் நடுவில் கோப்புகளை எழுதினால், கோப்பக அமைப்பு பாதியிலேயே சரிசெய்யப்பட்டு, குழப்பமான பிழைகள் மீண்டும் ஏற்பட வாய்ப்புள்ளது.

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

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

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

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

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-ஆக இயங்காது, ஒரு நொடி கூட இயங்காது. இது ஒரு உண்மையான பாதுகாப்பு மேம்பாடு ஆகும். இது root தேவைப்படும் entrypoint-ல் உள்ள எதையும் செயலிழக்கச் செய்யும். linuxserver images-ல், இந்தத் திட்டம் இதை ஒரு நியாயமான முயற்சியின் அடிப்படையில் ஆதரிக்கிறது மற்றும் அவர்கள் சோதித்த images-க்கு மட்டுமே இது பொருந்தும். இதன் கட்டுப்பாடுகள் குறிப்பிட்டவை: PUID மற்றும் PGID எந்த விளைவையும் ஏற்படுத்தாது, Docker Mods இயங்காது, custom services இயங்காது, மேலும் mounted volumes-ன் அனுமதிகளுக்கு (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 செல்லுபடியாகும் மற்றும் கோப்பு அணுகல் (file access) வழக்கம்போல வேலை செய்யும். பெயர் தேடல் (name lookup) மட்டுமே தோல்வியடையும்.

Rootless Docker

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

இந்த mapping-ஐ மீண்டும் கவனமாகப் படியுங்கள், ஏனெனில் இது வழக்கமான ஆலோசனையைத் தலைகீழாக மாற்றுகிறது. Rootless Docker-ல், root-ஆக எழுதும் ஒரு container, உங்களுக்குச் சொந்தமான கோப்புகளை உருவாக்குகிறது. UID 1000-ஆக எழுதும் ஒரு container, 100999-க்கு அருகில் உள்ள ஒரு subordinate ID-க்குச் சொந்தமான கோப்புகளை உருவாக்குகிறது, அவற்றை உங்கள் shell-ஆல் அணுக முடியாது. எனவே, rootful daemon-ல் சரியாக இருக்கும் PUID மதிப்பு, இங்கே தவறானது. இந்த இரண்டு வழிமுறைகளும் வெவ்வேறு அடுக்குகளில் ஒரே சிக்கலைத் தீர்க்கின்றன. அவற்றைச் சரிபார்க்காமல் ஒன்றன் மேல் ஒன்றாகப் பயன்படுத்தினால், அவற்றை நீக்க sudo தேவைப்படும் ஒரு directory-யை நீங்கள் பெறுவீர்கள். நீங்கள் 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 போன்ற ஒரு document workspace இந்த கடைசி வகையைச் சார்ந்தது. ஏனெனில் அதன் எந்த container-ம் PUID-ஐ வாசிப்பதில்லை, மேலும் அதன் database directory மற்றும் பதிவேற்றப்பட்ட கோப்புகளின் ownership, environment block-ல் உள்ள எதனாலும் அல்லாமல், runtime மூலமே தீர்மானிக்கப்படுகிறது.

மீடியா ஸ்டாக் சூழல்: கன்டெய்னர்களுக்கு இடையே பகிரப்பட்ட ஒரு குழு

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 மூலம் சேர்க்கப்பட்ட குழு, ஏற்கனவே திறந்திருக்கும் ஷெல் அமர்வில் (shell session) உடனடியாகத் தெரியாது.

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

பிறகு, ஸ்டாக்கில் உள்ள ஒவ்வொரு linuxserver கன்டெய்னரிலும் UMASK=002-ஐ அமைக்கவும். இதுவே பலரும் தவறவிடும் படிநிலை. இந்த இமேஜ்களில் இயல்பாக UMASK=022 இருக்கும், இது புதிய கோப்புகளிலிருந்து குழு எழுதும் பிட்டை (group write bit) நீக்கிவிடும். இதனால் கோப்புகள் 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

${PUID} பாணி மாற்றீட்டிற்காக Compose இந்தக் கோப்பைத் தானாகவே படிக்கும்; இதுவே நீங்கள் நற்சான்றிதழ்களுக்குப் (credentials) பயன்படுத்தும் அதே நுட்பமாகும். docker-compose.yml கோப்பில் மதிப்புகளை வைக்காமல் .env கோப்பில் வைத்திருக்கும் பழக்கம் இதற்கும் பொருந்தும், ஆனால் இந்த இரண்டு எண்களும் ரகசியமானவை அல்ல என்பது மட்டுமே வித்தியாசம்.

அமைப்பை நம்புவதற்குப் பதிலாக, முழுமையாகச் சரிபார்க்கவும். ஒரு கன்டெய்னருக்குள் இருந்து ஒரு கோப்பை எழுதி, ஹோஸ்டிலிருந்து அதைப் படிக்கவும்:

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) செயல்படவில்லை என்று அர்த்தம்; எனவே கன்டெய்னரை ரீஸ்டார்ட் செய்யாமல், மீண்டும் உருவாக்கியுள்ளீர்களா என்பதைச் சரிபார்க்கவும். சோதனை முடிந்ததும் 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 உட்பட பல official upstream images-கள், நிலையான built-in user-ஐக் கொண்டுள்ளன. அவை நீங்கள் user:-ஐப் பயன்படுத்த வேண்டும் அல்லது அதை மாற்றாமல் அப்படியே விட வேண்டும் என்று எதிர்பார்க்கின்றன. பிற்காலத்தில் நீங்கள் சேர்க்கும் infrastructure-க்கும் இது பொருந்தும். எனவே, ஒரே login-க்காக உங்கள் apps-க்கு முன்னால் Authentik-ஐ வைப்பது என்பது, PUID எதையும் வாசிக்காத official server, Postgres மற்றும் Redis images-களை இயக்குவதைக் குறிக்கும். அவற்றின் volume ownership, நீங்கள் configure செய்யக்கூடிய entrypoint-லிருந்து வராமல், runtime-லிருந்து அமையும்.

எனவே, ஒரு project-லிருந்து மற்றொரு project-க்கு environment block-ஐ நகலெடுக்கும் முன், ஒவ்வொரு image-ன் README கோப்பையும் சரிபார்க்கவும். நீங்கள் அமைக்கும் எந்தவொரு environment variable-ஐயும் Docker, அந்த container-க்குள் அனுப்பிவிடும்; உள்ளே இருக்கும் ஏதேனும் ஒன்று அதை வாசிக்கிறதா இல்லையா என்பது முக்கியமல்ல. எதையும் பயன்படுத்தாத ஒரு PUID எந்தப் பிழையையோ, எச்சரிக்கையையோ தராது, எந்த விளைவையும் ஏற்படுத்தாது. அந்த container அதன் Dockerfile-ல் கடைசியாகக் குறிப்பிடப்பட்ட user-ஆகவே இயங்கும், அது உருவாக்கும் கோப்புகளின் ownership மூலம் நீங்கள் அதைத் தெரிந்துகொள்ளலாம்.

FAQ

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

911 என்பது linuxserver.io images-ல் உள்ள abc பயனரின் UID மற்றும் GID ஆகும். இது காட்டப்பட்டால், PUID மற்றும் PGID ஆகியவற்றை அமைக்காமல் container தொடங்கப்பட்டுள்ளது என்று அர்த்தம்; எனவே அதன் init script இயல்பான அமைப்புகளையே வைத்துள்ளது. உங்கள் host-ல் 911 என்ற ID கொண்ட கணக்கு இல்லாததால், ls -l அந்த எண்களை அப்படியே காட்டுகிறது. 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:-ஐப் பயன்படுத்த வேண்டுமா?

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-ஐப் பெற கோப்பகங்களில் setgid bit-ஐ chmod 2775 மூலம் அமைக்கவும்.