ایک Docker Compose فائل میں مکمل arr stack

آپ کیا بنا رہے ہیں

Docker Compose پر مبنی arr stack چار containers پر مشتمل ہوتا ہے جو media library کا انتظام کرتے ہیں: indexer settings کے لیے Prowlarr، series کے لیے Sonarr، films کے لیے Radarr، اور download client کے طور پر qBittorrent۔ یہ Compose network پر service name کے ذریعے ایک دوسرے سے رابطہ کرتے ہیں اور host پر ایک ہی folder tree share کرتے ہیں۔ Installation مختصر ہے۔ stack کے برسوں تک درست کام کرنے یا ہر ہفتے مسائل پیدا کرنے کا فیصلہ volume layout کرتا ہے، اس لیے اس guide کا زیادہ تر حصہ اسی موضوع پر ہے۔

یہ stack آپ کے لیے content تلاش نہیں کرتا۔ Prowlarr میں وہی indexers شامل ہوتے ہیں جو آپ اس میں add کرتے ہیں، اور کون سے indexers استعمال کرنے ہیں، یہ آپ کا فیصلہ اور قانونی ذمہ داری ہے۔ یہ guide plumbing کا احاطہ کرتی ہے: users، paths، permissions، container networking، اور وہ checks جو ثابت کرتے ہیں کہ یہ درست کام کر رہا ہے۔

اگر آپ نے کبھی Compose file نہیں لکھی تو پہلے VPS کے لیے Docker Compose کی بنیادی باتیں پڑھیں۔ یہ post فرض کرتی ہے کہ docker compose version آپ کے server پر پہلے ہی کچھ output دکھاتا ہے۔ Docker Engine 28.0.0 یا اس کے بعد کا version استعمال کریں: پرانے releases میں اسی local network segment پر موجود hosts، localhost پر published ports تک پہنچ سکتے ہیں۔

ہارڈ لنکس کیوں ناکام ہوتے ہیں، اور یہی اصل مسئلہ کیوں ہے

جب Sonarr کسی download کو مکمل کرتا ہے تو وہ file کو آپ کی library میں import کرتا ہے۔ اگر download folder اور library folder ایک ہی filesystem پر ہوں اور hardlinking فعال ہو تو Sonarr hardlink بنانے کی کوشش کرتا ہے: یہ disk پر موجود اسی data کی طرف اشارہ کرنے والا دوسرا نام ہوتا ہے۔ اس میں اضافی جگہ یا وقت نہیں لگتا۔ torrent پرانے نام سے seeding جاری رکھتا ہے، جبکہ media server نئے نام سے file پڑھتا ہے۔

اگر دونوں folders مختلف filesystems پر ہوں تو kernel وہ link نہیں بنا سکتا۔ Sonarr copy پر واپس آ جاتا ہے۔ اب 40 GB کا ایک season disk پر 80 GB جگہ لیتا ہے اور input/output میں کئی منٹ لگتے ہیں۔ Sonarr cross-filesystem hardlink failures کو Trace level پر اور دیگر hardlink exceptions کو Debug level پر log کرتا ہے، اس لیے عام logs میں failure message کا نہ ہونا failure نہ ہونے کی ضمانت نہیں ہے۔ مقررہ disk allowance والے VPS پر لوگ اسی طرح ایک ہفتے میں disk space ختم کر بیٹھتے ہیں۔

اصل الجھن یہ ہے۔ container کے اندر bind mount filesystem boundary ہوتا ہے۔ /mnt/data/torrents کو /downloads اور /mnt/data/media کو /tv کے طور پر mount کریں تو دونوں ایک ہی host disk پر موجود ہونے کے باوجود Sonarr انہیں دو الگ mounts سمجھتا ہے اور ان کے درمیان hardlink نہیں بنا سکتا۔ LinuxServer.io کی official image documentation میں یہ بات براہ راست بیان کی گئی ہے: الگ الگ /downloads اور /tv paths استعمال کرنے سے hardlink بنانے کی صلاحیت ختم ہو جاتی ہے۔

حل ایک mount ہے۔ media کو استعمال کرنے والے ہر container کو ایک ہی single volume، /mnt/data:/data، دیں، اور ان کے استعمال کے تمام paths اسی کے اندر موجود folders ہوں۔ ایک mount point، ایک filesystem، اور کام کرنے والے hardlinks۔

صارف، گروپ اور فولڈرز بنائیں

کنٹینرز فائلیں numeric user id کے طور پر لکھتے ہیں، جسے PUID اور PGID مقرر کرتے ہیں۔ اپنا اکاؤنٹ استعمال کریں تاکہ آپ sudo کے بغیر SSH کے ذریعے ان فائلوں کو پڑھ اور edit کر سکیں۔

id -u
id -g

تازہ Ubuntu VPS پر دونوں عموماً 1000 دکھاتے ہیں۔ اب directory tree بنائیں۔ اسے اس disk پر رکھیں جس پر آپ کا media موجود ہے، اور پوری tree اسی ایک disk پر رکھیں۔

sudo mkdir -p /mnt/data/torrents/movies /mnt/data/torrents/tv
sudo mkdir -p /mnt/data/media/Movies /mnt/data/media/Shows
sudo chown -R 1000:1000 /mnt/data
sudo chmod -R 775 /mnt/data

آگے بڑھنے سے پہلے تصدیق کریں کہ یہ واقعی ایک ہی filesystem ہے:

df --output=source,target /mnt/data/torrents /mnt/data/media

دونوں lines میں ایک ہی source device دکھائی دینا چاہیے۔ دو مختلف devices کا مطلب ہے کہ hardlinks کبھی کام نہیں کریں گے، چاہے آپ container config میں کچھ بھی set کریں۔

library folders کے نام جان بوجھ کر Movies اور Shows رکھے گئے ہیں۔ اگر آپ پہلے ہی Jellyfin کو اپنے media server کے طور پر چلا رہے ہیں تو /mnt/data/media کو Jellyfin میں /media کے طور پر mount کریں۔ اس طرح اس کی libraries /media/Movies اور /media/Shows میں پہنچیں گی، بالکل وہاں جہاں وہ guide انہیں رکھتی ہے۔

ماحولیاتی فائل

ہر سرور کے مطابق تبدیل ہونے والی قدریں Compose فائل کے ساتھ موجود .env میں رکھیں۔

mkdir -p ~/arr && cd ~/arr

~/arr/.env لکھیں:

PUID=1000
PGID=1000
TZ=Etc/UTC
DATA_ROOT=/mnt/data

TZ کو اپنے zone پر سیٹ کریں، مثلاً Europe/Berlin۔ arr ایپلیکیشنز اسی zone میں tasks شیڈول کرتی ہیں اور log lines پر timestamp درج کرتی ہیں، اس لیے غلط value بعد میں ہر log کو مبہم بنا دیتی ہے۔

Compose فائل

~/arr/docker-compose.yml لکھیں:

services:
  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ./config/prowlarr:/config
    ports:
      - 127.0.0.1:9696:9696
    restart: unless-stopped

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ./config/sonarr:/config
      - ${DATA_ROOT}:/data
    ports:
      - 127.0.0.1:8989:8989
    restart: unless-stopped

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - ./config/radarr:/config
      - ${DATA_ROOT}:/data
    ports:
      - 127.0.0.1:7878:7878
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - ./config/qbittorrent:/config
      - ${DATA_ROOT}:/data
    ports:
      - 127.0.0.1:8080:8080
      - 6881:6881
      - 6881:6881/udp
    stop_grace_period: "10s"
    restart: unless-stopped

اس فائل میں چار چیزیں عملی طور پر اہم کام کرتی ہیں۔

${DATA_ROOT}:/data ان تین containers میں یکساں ہے جو media کو استعمال کرتے ہیں۔ Prowlarr کو یہ نہیں ملتا، کیونکہ Prowlarr کبھی media file نہیں کھولتا۔

ہر web port کو 127.0.0.1 سے bind کیا گیا ہے، اس لیے Docker اسے صرف loopback address پر publish کرتا ہے۔ سادہ 8989:8989 اسے ہر interface پر publish کرے گا، اور Docker کے اپنے firewall rules اس traffic کو ufw کے deny rule سے براہ راست آگے پہنچا دیں گے۔ یہ رویہ لوگوں کو مسلسل حیران کرتا ہے، اور Docker ports کو ufw کے راستے سے براہ راست کیوں publish کرتا ہے میں اس کی وضاحت کی گئی ہے۔

Port 6881 کو جان بوجھ کر تمام interfaces پر publish کیا گیا ہے۔ یہ torrent listening port ہے، اور incoming peer connections کے لیے اس تک رسائی ضروری ہے۔ یہاں بھی Docker کا یہی رویہ لاگو ہوتا ہے، اس لیے آپ کو اس کے لیے ufw rule کی ضرورت نہیں، اور ایسا rule شامل کرنے سے کچھ تبدیل نہیں ہوگا۔ Docker کی documentation، جسے November 8, 2026 کو چیک کیا گیا، کے مطابق published port تک جانے والا traffic ufw کے استعمال کردہ chains تک پہنچنے سے پہلے route ہو جاتا ہے، اس لیے sudo ufw allow 6881 اس port پر کوئی اثر نہیں ڈالتا۔ Container شروع ہوتے ہی Docker اسے host کے تمام interfaces پر publish کر دیتا ہے، اور ufw کا deny بھی اسے بند نہیں کرے گا۔ اگر کبھی آپ کو یہ محدود کرنا ہو کہ کون اس سے connect کر سکتا ہے، تو Docker کی documentation اس کے default iptables backend کے ساتھ DOCKER-USER chain میں rules کی طرف رہنمائی کرتی ہے؛ اس کا nftables backend اس کے بجائے الگ nftables table میں rules کا تقاضا کرتا ہے۔ ان services کے لیے ufw استعمال کریں جو Docker میں نہیں چل رہیں، جیسے SSH، اور اگر یہ tool نیا ہے تو VPS کے لیے ufw firewall کی بنیادی باتیں پڑھیں۔

Config directories ہر application کے لیے الگ ہیں، اور صرف media volume مشترک ہے۔ پہلی بار start کرنے سے پہلے انہیں بنائیں تاکہ یہ root کے بجائے آپ کے user کی ملکیت ہوں:

mkdir -p ~/arr/config/prowlarr ~/arr/config/sonarr ~/arr/config/radarr ~/arr/config/qbittorrent
docker compose up -d
docker compose ps

چاروں services کو running پڑھنا چاہیے۔ November 8, 2026 تک یہ images lscr.io پر publish کی گئی ہیں اور latest tag موجودہ stable release کی پیروی کرتا ہے، اس لیے اگر آپ چاہتے ہیں کہ upgrades اچانک ہونے کے بجائے باقاعدہ فیصلے کے تحت ہوں تو اس کے بجائے version tag مقرر کریں۔

ویب انٹرفیس تک محفوظ رسائی حاصل کریں

ویب انٹرفیس loopback پر bind ہیں۔ انہیں اپنی مشین سے SSH کے ذریعے forward کریں:

ssh -L 9696:127.0.0.1:9696 -L 8989:127.0.0.1:8989 \
    -L 7878:127.0.0.1:7878 -L 8080:127.0.0.1:8080 you@your-server

اب آپ کے browser میں http://127.0.0.1:8989 سرور پر Sonarr تک رسائی دیتا ہے۔ مستقل رسائی کے لیے stack کو متعدد ایپس کے لیے TLS certificates کے ساتھ Traefik کے پیچھے رکھیں، یا سرور تک اپنے زیر انتظام WireGuard VPN کے ذریعے رسائی حاصل کریں۔ تاہم VPN خود ان ports تک رسائی نہیں دیتا۔ 8 November 2026 کو دیکھی گئی Docker کی documentation کے مطابق، Docker Engine 28.0.0 یا اس کے بعد کے ورژن اور default bridge configuration میں، صرف Docker host ہی localhost address پر publish کیے گئے port تک رسائی حاصل کر سکتا ہے۔ VPN استعمال کرنے کے لیے یا تو اس کے ذریعے SSH tunnel جاری رکھیں، یا Compose file میں bindings کو 127.0.0.1 سے بدل کر VPN interface پر سرور کے اپنے address پر set کریں۔ ان میں سے کسی بھی application کو public internet پر صرف اپنی login page کے تحفظ کے ساتھ نہیں چلنا چاہیے۔ اگر آپ reverse proxy کا طریقہ اختیار کرتے ہیں اور چار الگ الگ application logins یاد رکھنے کے بجائے چاروں interfaces کے لیے ایک account چاہتے ہیں تو Authentik self-hosted single sign-on فراہم کرتا ہے، جسے Traefik ہر request پر forward auth کے ذریعے نافذ کر سکتا ہے۔ Proxy کے پیچھے Sonarr اور Radarr کے اپنے دو تقاضے ہیں۔ اس لیے انہیں Traefik کے ذریعے route کرنے سے پہلے Sonarr اور Radarr کو reverse proxy کے پیچھے چلانے کا طریقہ پڑھیں۔ اس میں Allowed Hosts entries شامل ہیں، جو Invalid Hostname errors کو روکتی ہیں، اور یہ وجہ بھی بیان کی گئی ہے کہ /api کو login کے بغیر گزرنے دینا ضروری ہے۔

qBittorrent پہلی بار start ہونے پر random administrator password بناتا ہے اور اسے container log میں لکھتا ہے۔ اسے پڑھیں، پھر web interface میں تبدیل کریں:

docker compose logs qbittorrent | grep -i password

اگر آپ password تبدیل نہیں کرتے تو ہر restart پر نیا random password بنتا ہے، اور آپ کو ہر بار logs میں اسے تلاش کرنا پڑے گا۔

ہر ایپلیکیشن کے اندر paths مقرر کریں

qBittorrent میں Options کھولیں، پھر Downloads پر جائیں، اور default save path کو /data/torrents پر مقرر کریں۔ incomplete-downloads folder کو اسی tree کے اندر رکھیں، مثلاً /data/torrents/incomplete۔ /data کے باہر کہیں مکمل ہونے والی download کو اس Compose file کے ذریعے library میں hardlink نہیں کیا جا سکتا۔

Sonarr میں Settings کھولیں، پھر Media Management پر جائیں، اور root folder /data/media/Shows شامل کریں۔ Radarr میں root folder /data/media/Movies ہے۔ یہ container کے اندر موجود paths ہیں۔ host path /mnt/data/media/Shows مسترد کر دیا جاتا ہے، کیونکہ container کے نقطۂ نظر سے یہ directory موجود نہیں ہے۔

Sonarr اور Radarr دونوں میں Settings کھولیں، پھر Download Clients پر جائیں، اور qBittorrent شامل کریں۔ host qbittorrent ہے اور port 8080 ہے۔ service name بطور hostname کام کرتا ہے، کیونکہ Compose چاروں containers کو internal DNS (domain name system) service والے ایک network پر رکھتا ہے۔ یہاں localhost استعمال نہ کریں: Sonarr container کے اندر localhost، Sonarr ہے۔

Remote Path Mappings کو خالی رہنے دیں۔ یہ feature اس path کو تبدیل کرنے کے لیے ہے جو download client report کرتا ہے، تاکہ وہ اس path میں تبدیل ہو جائے جسے arr application دیکھ سکتی ہے۔ ایک مشترکہ /data mount کے ساتھ دونوں containers پہلے ہی ہر path پر متفق ہیں۔ یہی وجہ ہے کہ یہ layout اختیار کرنا مفید ہے۔

Prowlarr کو Sonarr اور Radarr سے مربوط کریں

Prowlarr indexer کی تعریفیں دیگر ایپس میں بھیجتا ہے، اس لیے indexer کو دو بار configure کرنے کے بجائے ایک بار configure کریں۔ اس کے لیے ہر ایپ کی API (application programming interface) key درکار ہوتی ہے۔

Sonarr میں Settings کھولیں، پھر General کھول کر API key copy کریں۔ Prowlarr میں Settings کھولیں، پھر Apps کھولیں، Sonarr application شامل کریں، اور تین fields پُر کریں۔ Prowlarr Server http://prowlarr:9696 ہے۔ Sonarr Server http://sonarr:8989 ہے۔ API Key میں copy کی گئی value درج کریں۔ Test دبائیں۔ سبز result کا مطلب ہے کہ Prowlarr نے Compose network کے ذریعے Sonarr تک رسائی حاصل کر لی ہے۔ Radarr کے لیے http://radarr:7878 استعمال کرتے ہوئے یہی عمل دہرائیں۔

سرخ result میں connection was refused کا مطلب ہے کہ connection configure کیے گئے address اور port پر کسی listening service تک نہیں پہنچا۔ تصدیق کریں کہ container کے اندر سے نام resolve ہو رہا ہے:

docker compose exec prowlarr curl -sS -o /dev/null -w '%{http_code}\n' http://sonarr:8989

HTTP status code ثابت کرتا ہے کہ network path درست ہے۔ name resolution error کا مطلب ہے کہ service name resolve نہیں ہوا۔ اس کی spelling اور یہ بات چیک کریں کہ دونوں containers ایک ہی Compose network پر چل رہے ہیں۔

ثابت کریں کہ hardlinks واقعی بن رہے ہیں

link count دیکھے بغیر setup پر اعتماد نہ کریں۔ ایک item import ہونے کے بعد downloaded file اور library file کا موازنہ کریں:

stat -c '%i %h %n' /mnt/data/torrents/tv/*/*.mkv
stat -c '%i %h %n' /mnt/data/media/Shows/*/*/*.mkv

پہلا نمبر inode اور دوسرا link count ہے۔ ایک ہی filesystem پر ایک دوسرے کے hardlinks والی دو files میں ایک ہی inode اور کم از کم 2 کا link count دکھائی دیتا ہے؛ اضافی hardlinks اس count میں اضافہ کرتے ہیں۔ مختلف inodes کا مطلب ہے کہ files ایک دوسرے کے hardlinks نہیں ہیں، لیکن اس سے یہ ثابت نہیں ہوتا کہ hardlink بنانے کی کوشش ناکام ہوئی۔ Sonarr، hardlink setting غیر فعال ہونے پر، hardlink بنانے کی کوشش کیے بغیر بھی copy کرتا ہے۔ Cross-filesystem hardlink failures کو Trace level پر log کیا جاتا ہے، جبکہ دیگر hardlink exceptions کو Debug level پر log کیا جاتا ہے؛ اس لیے عام import logs لازماً وجہ نہیں بتاتے۔

disk کو بھی monitor کریں۔ import کے وقت df -h /mnt/data میں بمشکل تبدیلی آنی چاہیے، کیونکہ hardlink صرف ایک نام شامل کرتا ہے اور کوئی data نہیں۔

اصل میں کیا خراب ہوتا ہے

Import کے دوران permission errors کا مطلب ہے کہ container کا user id library folder میں لکھ نہیں سکتا۔ پیغام Access to the path ... is denied ہے۔ ls -ln /mnt/data/media سے تصدیق کریں کہ owner id آپ کے PUID سے مطابقت رکھتی ہے، اور یاد رکھیں کہ container کے کسی directory میں داخل ہونے سے پہلے اس پر execute bit ہونا ضروری ہے۔

Root-owned directories اس وقت بن سکتی ہیں جب host directory موجود ہونے سے پہلے container شروع کیا جائے، کیونکہ Docker غائب bind-mount directories خود بناتا ہے۔ Stack روکیں، directory کو chown کریں، اور اسے دوبارہ شروع کریں۔

qBittorrent سے torrent حذف کرنے کے بعد library file بھی غائب ملے تو دیکھیں کہ کون سے paths حذف ہوئے ہیں؛ صرف download حذف کرنے سے الگ library copy یا hardlink ختم نہیں ہوتا۔ حقیقی hardlink میں ایک نام حذف کرنے سے دوسرا برقرار رہتا ہے، کیونکہ data صرف اس وقت آزاد ہوتا ہے جب link count صفر ہو جائے۔

اگر disk آپ کے شامل کیے گئے media سے کہیں تیزی سے بھر رہی ہے تو یہ copy problem کی سب سے مہنگی صورت ہے۔ مزید storage خریدنے سے پہلے اوپر دیا گیا stat check چلائیں۔

VPS کو اس stack سے کیا درکار ہے

تینوں arr ایپس ہلکی ہیں۔ یہ indexers کو poll کرتی ہیں، ایک چھوٹے SQLite database میں لکھتی ہیں، اور files کے نام تبدیل کرتی ہیں۔ اصل load دوسری جگہ سے آتا ہے۔ بڑا torrent download کرتے وقت download client disk input اور output کو مکمل طور پر استعمال کر سکتا ہے، جبکہ اسی box پر video transcode کرنے والا media server CPU استعمال کرے گا۔ Media کو ایسے volume پر رکھیں جس میں حقیقی throughput ہو، اور اگر server پر کوئی دوسرا اہم کام بھی ہو تو download client کے لیے bandwidth limit مقرر کریں۔ ان اضافی کاموں کے لیے الگ سے وسائل مختص کریں، یہ فرض نہ کریں کہ کافی headroom موجود ہے: self-hosted AFFiNE workspace مزید چار containers اور ان کے پیچھے ایک database پر مشتمل ہے، جبکہ AFFiNE بنیادی استعمال کے لیے 2 GB RAM اور 10,000 الفاظ سے زیادہ documents کے لیے 4 GB RAM تجویز کرتا ہے۔ self-hosted openGym workout tracker جیسی single-purpose ایپ کے لیے اپنی TLS configuration رکھیں، اور اسے ایک سال کی training history دینے سے پہلے معلوم کریں کہ اس کا data folder کہاں ہے۔ جس سسٹم میں web application، Postgres database اور background worker queue شامل ہوں، وہ وسائل کے لحاظ سے AFFiNE کے قریب ہوتا ہے۔ اس لیے import کے دوران حد سامنے آنے سے پہلے فیصلہ کریں کہ self-hosted Chatwoot support desk اسی server پر ہونی چاہیے یا اپنے الگ server پر۔ Bursty workloads میں مزید احتیاط ضروری ہے، کیونکہ import کے ساتھ ٹکراؤ average کے بجائے peak load کی وجہ سے ہوتا ہے: اگر آپ self-hosted OneCLI جس میں ہر شخص کو اپنا sandboxed agent ملتا ہے استعمال کرنے پر غور کر رہے ہیں، تو اس کے شائع کردہ sizing numbers کو اس مقدار سے ملائیں جو qBittorrent کے پوری رفتار سے چلنے کے دوران حقیقتاً دستیاب ہو، نہ کہ اس مقدار سے جو idle box پر free -h دکھاتا ہے۔

FAQ

Sonarr فائلوں کو hardlink کرنے کے بجائے copy کیوں کرتا ہے؟

کیونکہ hardlinking غیر فعال ہے، یا hardlink بنانے کی کوشش ناکام ہو جاتی ہے۔ یہ اس وقت بھی ہوتا ہے جب container کے نقطۂ نظر سے source اور destination مختلف filesystems پر ہوں۔ دو الگ bind mounts، جیسے /downloads اور /tv، الگ mount points ہوتے ہیں، خواہ دونوں ایک ہی host disk سے آئے ہوں، اور hardlinks ان کے درمیان نہیں بن سکتے۔ ہر container میں ایک ہی parent directory کو /data کے طور پر mount کریں، اور اس کے اندر downloads اور library رکھیں۔ اس طرح link بنانا ممکن ہو جائے گا۔ دونوں files پر stat -c '%i %h %n' چلا کر نتیجہ تصدیق کریں۔ ایک ہی filesystem پر دونوں کو ایک ہی inode اور کم از کم 2 کا link count دکھانا چاہیے۔

مجھے کون سا PUID اور PGID استعمال کرنا چاہیے؟

اس host account کا numeric id استعمال کریں جو media tree کا مالک ہے۔ یہ id آپ id -u اور id -g سے حاصل کر سکتے ہیں۔ نئے Ubuntu VPS پر عموماً دونوں کے لیے 1000 ہوتا ہے۔ Stack کے ہر container میں یہی pair استعمال ہونا چاہیے، ورنہ ایک application ایسی files لکھے گی جن میں دوسری تبدیلی نہیں کر سکے گی۔ values تبدیل کرنے کے بعد docker compose up -d --force-recreate سے containers دوبارہ بنائیں، اور موجودہ files کی ملکیت chown -R سے درست کریں۔

کیا مجھے ان web interfaces کو internet پر expose کرنا ضروری ہے؟

نہیں، اور آپ کو ایسا نہیں کرنا چاہیے۔ Compose file میں ہر published port کو 127.0.0.1 سے bind کریں۔ اس کے بعد interfaces تک SSH tunnel کے ذریعے، یا server پر موجود reverse proxy کے ذریعے رسائی حاصل کریں۔ یہ reverse proxy TLS (transport layer security) terminate کرتا ہے اور اپنی authentication شامل کرتا ہے۔ Docker Engine 28.0.0 یا اس کے بعد کے version اور default bridge configuration کے ساتھ VPN اکیلا 127.0.0.1 پر published port تک رسائی نہیں دے سکتا، کیونکہ Docker اس published port کو صرف host کے اندر سے reachable بناتا ہے۔ Docker کے پرانے releases میں اسی local network segment پر موجود hosts، localhost پر published ports تک رسائی حاصل کر سکتے تھے۔ اگر آپ VPN کے ذریعے براہ راست رسائی چاہتے ہیں تو ports کو server کے VPN address پر publish کریں۔ انہیں براہ راست public interface پر publish کرنا بظاہر نظر آنے سے زیادہ خطرناک ہے، کیونکہ Docker اپنے firewall rules شامل کرتا ہے اور ufw کا deny rule اس traffic کو نہیں روک پائے گا۔

مجھے qBittorrent کا password کہاں ملے گا؟

LinuxServer.io image startup log میں admin user کے لیے temporary password لکھتی ہے۔ اسے پڑھنے کے لیے docker compose logs qbittorrent | grep -i password چلائیں، پھر Options اور Web UI کے تحت permanent password مقرر کریں۔ جب تک آپ اپنا password مقرر نہیں کرتے، ہر restart پر نیا temporary password generate ہوتا ہے۔

کیا Jellyfin وہی folders استعمال کر سکتا ہے؟

ہاں، اور layout کا مقصد بھی یہی ہے۔ /mnt/data/media کو اپنے media server میں /media کے طور پر mount کریں۔ اس کی libraries /media/Movies اور /media/Shows میں ہوں گی، جبکہ Sonarr اور Radarr انہی directories میں /data/media کے ذریعے files لکھیں گے۔ media server کو بھی وہی PUID اور PGID دیں، تاکہ وہ arr stack کی لکھی ہوئی files پڑھ سکے۔