Docker Compose-এ PUID এবং PGID কেন ব্যবহার করবেন?

PUID এবং PGID আসলে কী

PUID এবং PGID হলো দুটি environment variable যা নির্দিষ্ট কিছু container image স্টার্টআপের সময় পড়ে নেয়। Docker নিজে কখনো এগুলো পরীক্ষা করে না। এগুলো মূলত linuxserver.io-এর image এবং আরও কিছু নির্দিষ্ট image-এর ক্ষেত্রে ব্যবহৃত একটি কনভেনশন। তাই যে image-গুলো এই ভেরিয়েবলগুলো পড়ার জন্য তৈরি করা হয়নি, সেগুলো এগুলোকে উপেক্ষা করে।

একটি linuxserver.io image-এর ভেতরে abc নামে একজন ব্যবহারকারী থাকে, যাকে build করার সময় UID (user ID) 911 এবং GID (group ID) 911 দিয়ে তৈরি করা হয়। কন্টেইনারটি root হিসেবে শুরু হয় এবং এর init scriptগুলো চালায়। অন্য কোনো কাজ শুরু হওয়ার আগেই এই scriptগুলোর একটি সেই ব্যবহারকারীর আইডি পরিবর্তন করে ফেলে:

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

-o ফ্ল্যাগটি এমন একটি আইডি ব্যবহারের অনুমতি দেয় যা অন্য কোথাও আগে থেকেই ব্যবহৃত হচ্ছে। এরপর init প্রক্রিয়াটি privileges কমিয়ে দেয় এবং অ্যাপ্লিকেশনটিকে abc হিসেবে চালায়। তাই PUID=1000 কখনোই Docker-এর কাছে পৌঁছায় না। এই ভেরিয়েবলটি অ্যাপ্লিকেশন শুরু হওয়ার আগেই কন্টেইনারের ভেতরের একজন ব্যবহারকারীর আইডি পরিবর্তন করে দেয়। এর মানে হলো, অ্যাপ্লিকেশনটি যে ফাইলগুলো তৈরি করবে, সেগুলোর মালিকানা আপনার ডিস্কে 1000 হিসেবে থাকবে। 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 হিসেবে দেখাচ্ছে

যখন কোনো host account-এর সাথে ID-এর মিল পাওয়া যায় না, তখন ls -l নামের পরিবর্তে একটি numeric 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

এই আউটপুটটি নির্দেশ করে যে container-টি বিল্ট-ইন ডিফল্ট সেটিংস নিয়ে চলেছে। অনুমান না করে 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-টিকে নতুন করে তৈরি করে।

কেন আপনি কন্টেইনারের তৈরি করা ফাইল মুছে ফেলতে পারেন না

কার্নেল ফাইলের নাম নয়, বরং সংখ্যা (UID/GID) তুলনা করে। আপনার শেল UID 1000 হিসেবে চলে, কিন্তু ফাইলটি UID 911-এর মালিকানাধীন। ফাইলটি যে ডিরেক্টরিতে আছে সেটিও drwxr-xr-x এবং সেটিও 911-এর মালিকানাধীন, তাই গ্রুপ এবং অন্যান্য ব্যবহারকারীরা শুধু ফাইলটি পড়তে ও এক্সিকিউট করতে পারে, কিন্তু মুছে ফেলার জন্য প্রয়োজনীয় রাইট (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 সংক্রান্ত সমস্যা। ডকার যখন একটি empty named volume তৈরি করে এবং ইমেজে থাকা কোনো পাথের ওপর মাউন্ট করে, তখন এটি সেই পাথের বিষয়বস্তু ভলিউমে কপি করে নেয় (মালিকানা এবং পারমিশনসহ), ফলে অ্যাপ্লিকেশনটি তার নিজের মালিকানাধীন একটি ডিরেক্টরি খুঁজে পায়। কিন্তু bind mount-এর ক্ষেত্রে এমনটি ঘটে না: ডকার আপনার হোস্ট ডিরেক্টরিটিকে ঠিক যেমন আছে সেভাবেই মাউন্ট করে। এই পার্থক্যটিই হলো কখন 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 স্টার্টআপের সময় ঠিক তিনটি পাথ /app, /config এবং /defaults-এর মালিকানা পরিবর্তন (chown) করে। আপনার মিডিয়া মাউন্টগুলো এই তালিকার অন্তর্ভুক্ত নয়। /data, /downloads এবং /tv সরাসরি অ্যাপ্লিকেশনের কাছে কোনো পরিবর্তন ছাড়াই পৌঁছে দেওয়া হয়। তাই যদি এই মাউন্টগুলোর হোস্ট সাইডে এমন মালিকানা থাকে যা কন্টেইনার ব্যবহারকারী লিখতে পারে না, তবে কন্টেইনারটি সঠিকভাবে চালু হবে এবং ব্যানারে সঠিক UID দেখাবে, কিন্তু প্রথমবার ইমপোর্ট করার সময় ব্যর্থ হবে।

এটিই সঠিক আচরণ। প্রতিবার কন্টেইনার চালু হওয়ার সময় বারো টেরাবাইট মিডিয়া লাইব্রেরিতে রিকার্সিভ chown চালানো একটি বিপর্যয় ডেকে আনবে। এর অর্থ হলো মিডিয়া ডিরেক্টরিগুলোর দায়িত্ব আপনার এবং এগুলোতে পারমিশন সংক্রান্ত সমস্যা হওয়ার সম্ভাবনা সবচেয়ে বেশি।

ব্যবহারকারী নিয়ন্ত্রণের তিনটি উপায় এবং প্রতিটি কখন প্রযোজ্য

PUID এবং PGID এনভায়রনমেন্ট ভেরিয়েবল

এটি শুধুমাত্র সেইসব ইমেজে কাজ করে যার এন্ট্রি পয়েন্ট এগুলো রিড করতে পারে। এটি জনপ্রিয় কারণ কন্টেইনারটি শুরুতে root হিসেবেই চালু হয়, নিজের সেটআপ সম্পন্ন করে, /config ঠিক করে এবং তারপর প্রিভিলেজ বা বিশেষ সুবিধা ত্যাগ করে। Docker Mods এবং কাস্টম ইনিট স্ক্রিপ্টগুলো এতে কাজ করতে থাকে। এর অসুবিধা হলো, আপনি প্ল্যাটফর্ম ফিচারের পরিবর্তে একটি কনভেনশনের ওপর নির্ভর করছেন এবং ভেরিয়েবলের নামগুলো সব প্রজেক্টে একই থাকে না।

Compose-এ user: কি (key)

এটি একটি প্রকৃত 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 রিপোর্ট করে। আইডিটি বৈধ এবং ফাইল অ্যাক্সেস স্বাভাবিকভাবেই কাজ করে। শুধুমাত্র নাম খোঁজার প্রক্রিয়াটি ব্যর্থ হয়।

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টি সাবঅর্ডিনেট আইডি আশা করে।

এই ম্যাপিংটি পুনরায় পড়ুন, কারণ এটি প্রচলিত পরামর্শের বিপরীত। rootless Docker-এ, root হিসেবে লেখা কন্টেইনার এমন ফাইল তৈরি করে যার মালিক আপনি। UID 1000 হিসেবে লেখা কন্টেইনার এমন ফাইল তৈরি করে যার মালিক 100999-এর কাছাকাছি কোনো সাবঅর্ডিনেট আইডি, যা আপনার শেল অ্যাক্সেস করতে পারে না। তাই rootful ডেমোনে যে PUID সঠিক, এখানে তা ভুল। এই দুটি মেকানিজম ভিন্ন ভিন্ন স্তরে একই সমস্যার সমাধান করে, এবং যাচাই না করে এগুলো একসাথে ব্যবহার করলে এমন ডিরেক্টরি তৈরি হতে পারে যা ডিলিট করতে আপনার sudo প্রয়োজন হবে। আপনি যদি rootless ব্যবহার করেন, তবে কোনো লাইব্রেরি মাইগ্রেট করার আগে আপনার নিজের সার্ভারে একটি ফাইল লিখে তার মালিকানা পরীক্ষা করে নিন।

একটি সিঙ্গেল VPS-এ বেশিরভাগ self-hosted স্ট্যাকের জন্য rootful ডেমোনে PUID এবং PGID ব্যবহার করাই বাস্তবসম্মত পছন্দ, কারণ ইমেজগুলো এভাবেই তৈরি এবং নথিবদ্ধ করা হয়েছে। user: ব্যবহার করুন যখন ইমেজের README-তে লেখা থাকে যে ইমেজটি এর জন্য পরীক্ষিত, অথবা যখন আপনি এমন কোনো অফিসিয়াল আপস্ট্রিম ইমেজ চালাচ্ছেন যাতে PUID-এর কোনো সমর্থন নেই।

মিডিয়া স্ট্যাকের ক্ষেত্রে: কন্টেইনারগুলোর মধ্যে একটি শেয়ারড গ্রুপ

একটি 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 শেয়ার করে।

এরপর স্ট্যাকের প্রতিটি 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 ভেরিয়েবলটি কার্যকর হয়নি; সেক্ষেত্রে কন্টেইনারটি রিস্টার্ট না করে পুনরায় তৈরি (recreate) করেছেন কি না তা নিশ্চিত করুন। কাজ শেষ হলে rm /srv/media/downloads/permtest দিয়ে টেস্ট ফাইলটি মুছে ফেলুন।

কোন ইমেজ কোন ভেরিয়েবল ব্যবহার করে

linuxserver.io ইমেজগুলো PUID, PGID এবং UMASK ব্যবহার করে। Paperless-ngx একই ধারণার জন্য ভিন্ন নাম ব্যবহার করে: USERMAP_UID এবং USERMAP_GID, যার উভয়ই ডিফল্ট হিসেবে 1000 সেট করা থাকে এবং এর ডকুমেন্টেশন আপনাকে এগুলো id -u এবং id -g থেকে পড়ার পরামর্শ দেয়। সাধারণ ডাটাবেস এবং ওয়েব সার্ভার ইমেজসহ অনেক অফিসিয়াল আপস্ট্রিম ইমেজ একটি নির্দিষ্ট বিল্ট-ইন ইউজার ব্যবহার করে এবং প্রত্যাশা করে যে আপনি user: ব্যবহার করবেন অথবা সেটি অপরিবর্তিত রাখবেন।

তাই প্রজেক্টের মধ্যে এনভায়রনমেন্ট ব্লক কপি করার আগে প্রতিটি ইমেজের README ফাইল চেক করুন। আপনি যে এনভায়রনমেন্ট ভেরিয়েবলই সেট করুন না কেন, Docker তা কন্টেইনারের ভেতরে পাঠিয়ে দেয়, সেটি কোনো কিছু ব্যবহার করুক বা না করুক। এমন একটি PUID যা কোনো কিছু ব্যবহার করে না, তা কোনো এরর বা ওয়ার্নিং তৈরি করে না এবং এর কোনো প্রভাবও থাকে না। কন্টেইনারটি তার নিজস্ব Dockerfile-এর শেষে যে ইউজার সেট করা ছিল সেই ইউজার হিসেবেই চলে, এবং এটি যে ফাইলগুলো তৈরি করে তার মালিকানা (ownership) দেখে আপনি তা বুঝতে পারবেন।

FAQ

আমার Docker ফাইলগুলোর মালিকানা কেন 911:911 দেখাচ্ছে?

911 হলো linuxserver.io ইমেজগুলোতে বিল্ট-ইন থাকা abc ব্যবহারকারীর UID এবং GID। এটি দেখার মানে হলো কন্টেইনারটি PUID এবং PGID সেট না করেই চালু হয়েছে, তাই এর init স্ক্রিপ্ট বিল্ট-ইন ডিফল্ট মানগুলোই রেখে দিয়েছে। ls -l এই সংখ্যাগুলো সরাসরি দেখায় কারণ আপনার হোস্ট মেশিনে 911 আইডিধারী কোনো অ্যাকাউন্ট নেই, তাই দেখানোর মতো কোনো নামও নেই। 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-তে যদি উল্লেখ থাকে যে এটি non-root অপারেশনের জন্য পরীক্ষিত, তখন user: ব্যবহার করুন। linuxserver ইমেজে user: সেট করলে PUID এবং PGID নিষ্ক্রিয় হয়ে যায়, Docker Mods এবং কাস্টম সার্ভিসগুলো চলা বন্ধ হয়ে যায় এবং প্রতিটি মাউন্ট করা ভলিউমের পারমিশনের দায়িত্ব আপনার ওপর বর্তায়।

Sonarr-এ সঠিক PUID থাকা সত্ত্বেও ফাইল সরাতে পারছে না। সমস্যা কোথায়?

ক্রমানুসারে তিনটি বিষয় পরীক্ষা করুন। প্রথমত, মিডিয়া মাউন্ট নিজেই: init শুধুমাত্র /app, /config এবং /defaults-এর মালিকানা পরিবর্তন করে, তাই /data বা /downloads হোস্ট মেশিনে তাদের নিজস্ব মালিকানাই বজায় রাখে। দ্বিতীয়ত, শেয়ার করা গ্রুপ: যদি ডাউনলোড ক্লায়েন্ট এবং Sonarr ভিন্ন GID-তে চলে, তবে কেউই অন্যের ফাইল পরিবর্তন করতে পারবে না, তাই স্ট্যাকের প্রতিটি কন্টেইনারকে একই PGID দিন। তৃতীয়ত, umask: ইমেজের ডিফল্ট UMASK=022 ফাইলগুলোকে 0644 হিসেবে লেখে যেখানে কোনো গ্রুপ রাইট বিট থাকে না, যা শেয়ার করা গ্রুপের উদ্দেশ্যকেই ব্যর্থ করে দেয়। UMASK=002 সেট করুন এবং chmod 2775 দিয়ে ডিরেক্টরিগুলোতে setgid বিট সেট করুন যাতে নতুন ফাইলগুলো গ্রুপটি উত্তরাধিকারসূত্রে পায়।