Docker Compose-ல் Prowlarr, Sonarr, Radarr அமைப்பது எப்படி

நீங்கள் உருவாக்குவது என்ன

Docker Compose arr stack என்பது மீடியா லைப்ரரியை நிர்வகிக்கும் நான்கு containers-களைக் கொண்டது: indexer அமைப்புகளுக்கு Prowlarr, தொடர்களுக்கு (series) Sonarr, திரைப்படங்களுக்கு Radarr, மற்றும் download client-ஆக qBittorrent. இவை Compose network வழியாக service name மூலம் ஒன்றோடொன்று தொடர்புகொள்கின்றன, மேலும் host-ல் உள்ள ஒரே folder tree-ஐப் பகிர்ந்து கொள்கின்றன. இதன் நிறுவல் குறுகியது. இந்த stack பல ஆண்டுகள் சீராக இயங்குமா அல்லது வாரந்தோறும் சிக்கல்களைத் தருமா என்பதைத் தீர்மானிப்பது volume layout தான், எனவே இந்த வழிகாட்டியின் பெரும்பகுதி அதைப் பற்றியது.

இந்த stack உங்களுக்காக உள்ளடக்கத்தைத் தேடித் தராது. நீங்கள் சேர்க்கும் indexer-களை Prowlarr வைத்திருக்கும்; எந்த indexer-களைப் பயன்படுத்துவது என்பது உங்கள் முடிவு மற்றும் உங்கள் சட்டப்பூர்வப் பொறுப்பு. இந்த வழிகாட்டி plumbing எனப்படும் அடிப்படை அமைப்புகளைப் பற்றியது: பயனர்கள், paths, அனுமதிகள், container networking, மற்றும் அது சரியாக இயங்குவதை உறுதிப்படுத்தும் சோதனைகள்.

நீங்கள் இதுவரை Compose file எழுதியதில்லை என்றால், முதலில் the Docker Compose basics for a VPS-ஐப் படிக்கவும். இந்த இடுகை உங்கள் server-ல் docker compose version ஏற்கனவே ஏதேனும் வெளியீட்டைத் தருகிறது என்று கருதுகிறது. Docker Engine 28.0.0 அல்லது அதற்குப் பிந்தைய பதிப்பைப் பயன்படுத்தவும்: பழைய releases-ல், ஒரே local network segment-ல் உள்ள hosts, localhost-க்கு publish செய்யப்பட்ட ports-ஐ அணுக அனுமதிக்கும்.

Hardlinks ஏன் செயலிழக்கின்றன, இது ஏன் மிக முக்கியமான காரணியாகிறது

Sonarr ஒரு பதிவிறக்கத்தை முடித்ததும், அந்த கோப்பை உங்கள் library-க்குள் இறக்குமதி செய்கிறது. பதிவிறக்க கோப்புறையும் (download folder) library கோப்புறையும் ஒரே filesystem-ல் இருந்து, hardlinking வசதி இயக்கப்பட்டிருந்தால், Sonarr ஒரு hardlink-ஐ உருவாக்க முயற்சிக்கும்: இது வட்டில் (disk) உள்ள அதே தரவைச் சுட்டிக்காட்டும் இரண்டாவது பெயராகும். இதற்கு கூடுதல் இடமோ அல்லது நேரமோ தேவைப்படாது. உங்கள் media server புதிய பெயரில் கோப்பை வாசிக்கும் அதே வேளையில், torrent பழைய பெயரில் தொடர்ந்து seeding ஆகும்.

இந்த இரண்டு கோப்புறைகளும் வெவ்வேறு filesystem-களில் இருந்தால், kernel-ஆல் அந்த இணைப்பை உருவாக்க முடியாது. அப்போது Sonarr தானாகவே copy செய்யும் முறைக்கு மாறிவிடும். இதனால் 40 GB அளவுள்ள ஒரு season, 80 GB வட்டு இடத்தைப் பிடிப்பதோடு, பல நிமிடங்கள் input மற்றும் output நேரத்தையும் எடுத்துக்கொள்ளும். Sonarr, cross-filesystem hardlink தோல்விகளை Trace level-லும், பிற hardlink விதிவிலக்குகளை Debug level-லும் பதிவு செய்கிறது. எனவே, சாதாரண logs-களில் தோல்விக்கான செய்தி எப்போதும் இருக்காது. குறிப்பிட்ட அளவு வட்டு வசதி கொண்ட VPS-ல், இதுவே ஒரு வாரத்தில் வட்டு இடம் தீர்ந்துபோகக் காரணமாகிறது.

இங்கேதான் சிக்கல் உள்ளது. ஒரு container-க்குள், bind mount என்பது ஒரு filesystem எல்லையாகக் கருதப்படுகிறது. /mnt/data/torrents-ஐ /downloads ஆகவும், /mnt/data/media-ஐ /tv ஆகவும் mount செய்தால், அவை இரண்டும் ஒரே host disk-ல் இருந்தாலும், Sonarr அவற்றை இரண்டு தனித்தனி mount-களாகவே பார்க்கும். இதனால் அவற்றுக்கிடையே hardlink செய்ய முடியாது. அதிகாரப்பூர்வ LinuxServer.io image ஆவணங்கள் இதை நேரடியாகக் குறிப்பிடுகின்றன: தனித்தனி /downloads மற்றும் /tv பாதைகளைப் பயன்படுத்துவது hardlink செய்யும் திறனைப் பாதிக்கும்.

இதற்கான தீர்வு ஒரே ஒரு mount-ஐப் பயன்படுத்துவதாகும். Media-வை அணுகும் ஒவ்வொரு container-க்கும் ஒரே volume-ஐ, அதாவது /mnt/data:/data-ஐ வழங்க வேண்டும். அவை பயன்படுத்தும் ஒவ்வொரு பாதையும் அதற்குள் இருக்கும் ஒரு கோப்புறையாக இருக்க வேண்டும். ஒரே mount point, ஒரே filesystem, இதுவே hardlinks சரியாகச் செயல்பட உதவும்.

பயனர், குழு மற்றும் கோப்புறைகளை உருவாக்குதல்

Containers கோப்புகளை ஒரு எண் சார்ந்த பயனர் அடையாளத்துடன் (numeric user id) எழுதுகின்றன, இது PUID மற்றும் PGID மூலம் அமைக்கப்படுகிறது. உங்கள் சொந்த கணக்கைப் பயன்படுத்தவும், அப்போதுதான் sudo தேவைப்படாமல் SSH வழியாக அந்த கோப்புகளை உங்களால் படிக்கவும் திருத்தவும் முடியும்.

id -u
id -g

புதிய Ubuntu VPS-ல் இவை இரண்டும் பொதுவாக 1000 என்று காட்டும். இப்போது கோப்பு கட்டமைப்பை (tree) உருவாக்கவும். உங்கள் மீடியா கோப்புகள் இருக்கும் வட்டில் இதை வைக்கவும், முழு கட்டமைப்பையும் அந்த ஒரே வட்டில் வைத்திருக்கவும்.

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

இரண்டு வரிகளும் ஒரே source சாதனத்தைக் காட்ட வேண்டும். இரண்டு வெவ்வேறு சாதனங்கள் இருந்தால், container அமைப்பில் நீங்கள் எதை அமைத்தாலும் hardlinks வேலை செய்யாது.

நூலகக் கோப்புறைகள் (library folders) வேண்டுமென்றே Movies மற்றும் Shows என்று பெயரிடப்பட்டுள்ளன. நீங்கள் ஏற்கனவே Jellyfin-ஐ உங்கள் மீடியா சர்வராக இயக்குகிறீர்கள் என்றால், /mnt/data/media-ஐ Jellyfin-ல் /media ஆக mount செய்யவும். அதன் நூலகங்கள் /media/Movies மற்றும் /media/Shows ஆகிய இடங்களில் அமையும், இது அந்த வழிகாட்டி குறிப்பிடும் அதே இடமாகும்.

Environment file

ஒவ்வொரு server-க்கும் மாறுபடும் மதிப்புகளை .env-ல், Compose file-க்கு அருகிலேயே வைத்திருக்கவும்.

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

~/arr/.env-ஐ உருவாக்கவும்:

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

TZ-ஐ உங்கள் zone-க்கு ஏற்ப அமைக்கவும், உதாரணமாக Europe/Berlin. Arr applications அந்த zone-ல் தான் பணிகளைத் திட்டமிடுகின்றன மற்றும் log வரிகளைப் பதிவு செய்கின்றன, எனவே தவறான மதிப்பை அமைத்தால் பிற்காலத்தில் அனைத்து 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

அந்தக் கோப்பில் உள்ள நான்கு விஷயங்கள் உண்மையான பணிகளைச் செய்கின்றன.

மீடியா கோப்புகளை அணுகும் மூன்று container-களிலும் ${DATA_ROOT}:/data ஒரே மாதிரியாக உள்ளது. Prowlarr ஒருபோதும் மீடியா கோப்பைத் திறக்காது என்பதால், அதற்கு இது தேவையில்லை.

ஒவ்வொரு web port-ம் 127.0.0.1-உடன் இணைக்கப்பட்டுள்ளதால், Docker அதை loopback முகவரியில் மட்டுமே வெளியிடுகிறது. ஒரு சாதாரண 8989:8989 அனைத்து interface-களிலும் அதை வெளியிடும், மேலும் Docker-ன் சொந்த firewall விதிகள் அந்த traffic-ஐ ufw deny விதியைத் தாண்டி நேரடியாக அனுமதிக்கும். இந்தச் செயல்பாடு பயனர்களைத் தொடர்ந்து ஆச்சரியப்படுத்துகிறது, இது Docker ஏன் ufw-ஐத் தாண்டி ports-ஐ வெளியிடுகிறது என்பதில் விளக்கப்பட்டுள்ளது.

Port 6881 வேண்டுமென்றே அனைத்து interface-களிலும் வெளியிடப்படுகிறது. இது torrent listening port ஆகும், உள்வரும் peer இணைப்புகளுக்கு இது அணுகக்கூடியதாக இருக்க வேண்டும். அதே Docker செயல்பாடு இங்கும் பொருந்தும், எனவே இதற்கு ufw விதி தேவையில்லை, மேலும் ஒன்றைச் சேர்ப்பது எதையும் மாற்றாது. நவம்பர் 8, 2026 அன்று சரிபார்க்கப்பட்ட Docker ஆவணங்களின்படி, வெளியிடப்பட்ட port-க்கான traffic, ufw பயன்படுத்தும் chains-ஐ அடைவதற்கு முன்பே routing செய்யப்படுகிறது, எனவே sudo ufw allow 6881 இந்த port-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது. container தொடங்கியவுடன் Docker அதை அனைத்து host interface-களிலும் வெளியிடுகிறது, மேலும் ஒரு ufw deny விதியும் அதை மூடாது. இதனுடன் யார் இணையலாம் என்பதைக் கட்டுப்படுத்த வேண்டியிருந்தால், Docker ஆவணங்கள் அதன் DOCKER-USER chain-ல் விதிகளை அமைக்கப் பரிந்துரைக்கின்றன (default iptables backend-க்கு); அதன் nftables backend-க்கு தனி nftables table-ல் விதிகள் தேவைப்படும். SSH போன்ற Docker-ல் இயங்காத சேவைகளுக்கு ufw-ஐப் பயன்படுத்தவும், இந்த கருவி உங்களுக்குப் புதியது என்றால் VPS-க்கான ufw firewall அடிப்படைகள் என்பதைப் படிக்கவும்.

Config directories ஒவ்வொரு application-க்கும் தனித்தனியாக உள்ளன, மீடியா volume மட்டுமே பகிரப்படுகிறது. முதல் முறை தொடங்குவதற்கு முன்பே அவற்றை உருவாக்கவும், அப்போதுதான் அவை root-க்கு பதிலாக உங்கள் user-ன் உரிமையில் இருக்கும்:

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

நான்கு சேவைகளும் running-ஐப் படிக்க வேண்டும். நவம்பர் 8, 2026 நிலவரப்படி, இந்த images lscr.io-ல் வெளியிடப்படுகின்றன மற்றும் latest tag தற்போதைய stable release-ஐப் பின்பற்றுகிறது. எனவே, மேம்படுத்தல்கள் தானாக நிகழ்வதை விட உங்கள் முடிவாக இருக்க வேண்டும் எனில், ஒரு குறிப்பிட்ட version tag-ஐப் பயன்படுத்தவும்.

இணைய இடைமுகங்களை பாதுகாப்பாக அணுகுதல்

இணைய இடைமுகங்கள் loopback முகவரியுடன் பிணைக்கப்பட்டுள்ளன. உங்கள் கணினியிலிருந்து 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

இப்போது உங்கள் உலாவியில் http://127.0.0.1:8989 என உள்ளிடுவதன் மூலம் சர்வரில் உள்ள Sonarr-ஐ அணுகலாம். நிரந்தர அணுகலுக்கு, இந்த stack-ஐ பல செயலிகளுக்கான TLS சான்றிதழ்களுடன் கூடிய Traefik பின்னால் வைக்கவும் அல்லது நீங்கள் சொந்தமாக நடத்தும் WireGuard VPN வழியாக சர்வரை அணுகவும். இருப்பினும், VPN மட்டும் இந்த ports-ஐ நேரடியாக அணுக முடியாது. நவம்பர் 8, 2026 அன்று சரிபார்க்கப்பட்ட Docker ஆவணங்களின்படி, Docker Engine 28.0.0 அல்லது அதற்குப் பிந்தைய பதிப்புகளில், இயல்புநிலை bridge அமைப்பில், localhost முகவரியில் வெளியிடப்பட்ட port-ஐ Docker host மட்டுமே அணுக முடியும். VPN-ஐப் பயன்படுத்த, SSH tunnel-ஐ அதன் வழியாகத் தொடர்ந்து இயக்கவும் அல்லது Compose கோப்பில் உள்ள bindings-ஐ 127.0.0.1 என்பதிலிருந்து VPN இடைமுகத்தில் உள்ள சர்வரின் சொந்த முகவரிக்கு மாற்றவும். இந்த செயலிகள் எதையும், அவற்றின் சொந்த login பக்கத்தை மட்டும் வைத்துக்கொண்டு பொது இணையத்தில் (public internet) வைக்கக்கூடாது. நீங்கள் reverse proxy முறையைத் தேர்ந்தெடுத்து, நான்கு தனித்தனி login விவரங்களை நிர்வகிப்பதற்குப் பதிலாக, நான்கு இடைமுகங்களுக்கும் ஒரே கணக்கைப் பயன்படுத்த விரும்பினால், Authentik உங்களுக்கு self-hosted single sign-on வசதியை வழங்குகிறது; இதை Traefik மூலம் ஒவ்வொரு கோரிக்கையிலும் forward auth ஆக அமல்படுத்தலாம். Proxy-க்கு பின்னால் Sonarr மற்றும் Radarr-ஐ இயக்கும்போது இரண்டு சிக்கல்கள் உள்ளன. எனவே, அவற்றை Traefik வழியாக வழிநடத்தும் முன், Invalid Hostname பிழைகளைத் தவிர்க்க தேவையான Allowed Hosts உள்ளீடுகள் மற்றும் /api ஏன் login-ஐத் தவிர்க்க வேண்டும் என்பது குறித்த Sonarr மற்றும் Radarr-ஐ reverse proxy-க்கு பின்னால் இயக்குவது எப்படி என்ற கட்டுரையைப் படிக்கவும்.

qBittorrent முதல்முறை தொடங்கும்போது ஒரு சீரற்ற (random) நிர்வாகி கடவுச்சொல்லை உருவாக்கி, அதை container log-ல் பதிவிடும். அதை வாசித்துவிட்டு, இணைய இடைமுகத்தில் மாற்றவும்:

docker compose logs qbittorrent | grep -i password

நீங்கள் கடவுச்சொல்லை மாற்றவில்லை என்றால், ஒவ்வொரு முறை restart செய்யும்போதும் புதிய சீரற்ற கடவுச்சொல் உருவாக்கப்படும். இதனால் ஒவ்வொரு முறையும் நீங்கள் logs-ஐப் பார்க்க வேண்டியிருக்கும்.

ஒவ்வொரு application-க்குள்ளும் பாதைகளை (paths) அமைத்தல்

qBittorrent-ல், Options என்பதைத் திறந்து, பின் Downloads என்பதைத் தேர்ந்தெடுக்கவும். இயல்புநிலை சேமிப்புப் பாதையை (default save path) /data/torrents என அமைக்கவும். முழுமையடையாத பதிவிறக்கங்களுக்கான (incomplete-downloads) கோப்புறையை அதே கட்டமைப்பிற்குள், உதாரணமாக /data/torrents/incomplete என வைத்திருக்கவும். /data-க்கு வெளியே எங்கு பதிவிறக்கம் முடிவடைந்தாலும், இந்த Compose கோப்பைப் பயன்படுத்தி அதை library-க்குள் hardlink செய்ய முடியாது.

Sonarr-ல், Settings என்பதைத் திறந்து, பின் Media Management என்பதைத் தேர்ந்தெடுக்கவும். அங்கு root கோப்புறையாக /data/media/Shows என்பதைச் சேர்க்கவும். Radarr-ல் root கோப்புறை /data/media/Movies ஆகும். இவை container-க்குள் இருக்கும் பாதைகள். host பாதையான /mnt/data/media/Shows நிராகரிக்கப்படும், ஏனெனில் container-ன் பார்வையில் அந்த directory இல்லை.

Sonarr மற்றும் Radarr ஆகிய இரண்டிலும், Settings என்பதைத் திறந்து, பின் Download Clients என்பதைத் தேர்ந்தெடுக்கவும். அங்கு qBittorrent-ஐச் சேர்க்கவும். host என்பது qbittorrent மற்றும் port என்பது 8080 ஆகும். Compose அனைத்து நான்கு container-களையும் ஒரே network-ல், internal DNS (domain name system) சேவையுடன் இணைப்பதால், service பெயர் hostname-ஆகச் செயல்படுகிறது. இங்கே localhost-ஐப் பயன்படுத்த வேண்டாம்: Sonarr container-க்குள், localhost என்பது Sonarr-ஐயே குறிக்கும்.

Remote Path Mappings-ஐ காலியாக விடவும். பதிவிறக்க client தெரிவிக்கும் பாதையை, arr application பார்க்கக்கூடிய பாதையாக மாற்றவே இந்த அம்சம் உள்ளது. ஒரே பகிரப்பட்ட /data mount இருப்பதால், இரண்டு container-களும் அனைத்துப் பாதைகளையும் ஒரே மாதிரியாகக் கொள்கின்றன. இந்த layout-ஐ உருவாக்குவதற்கு இதுவே இரண்டாவது முக்கியக் காரணமாகும்.

Prowlarr-ஐ Sonarr மற்றும் Radarr உடன் இணைத்தல்

Prowlarr, indexer வரையறைகளை மற்ற applications-க்கு அனுப்புகிறது. எனவே, ஒரு indexer-ஐ இருமுறை உள்ளமைப்பதற்குப் பதிலாக, ஒருமுறை மட்டும் உள்ளமைத்தால் போதுமானது. இதற்கு ஒவ்வொரு application-லிருந்தும் ஒரு API (application programming interface) key தேவைப்படும்.

Sonarr-ல், Settings-ஐத் திறந்து, பின் General-க்குச் சென்று, API key-ஐ நகலெடுக்கவும். Prowlarr-ல், Settings-ஐத் திறந்து, Apps-க்குச் சென்று, ஒரு Sonarr application-ஐச் சேர்க்கவும். பின்வரும் மூன்று புலங்களை நிரப்பவும். Prowlarr Server என்பது http://prowlarr:9696. Sonarr Server என்பது http://sonarr:8989. API Key என்பது நீங்கள் நகலெடுத்த மதிப்பு. Test என்பதை அழுத்தவும். பச்சை நிற முடிவு, Prowlarr ஆனது Compose network வழியாக Sonarr-ஐ அடைந்துவிட்டது என்பதைக் குறிக்கிறது. Radarr-க்கு http://radarr:7878-ல் இதையே மீண்டும் செய்யவும்.

இணைப்பு மறுக்கப்பட்டதாகக் காட்டும் சிவப்பு நிற முடிவு, உள்ளமைக்கப்பட்ட முகவரி மற்றும் port-ல் இயங்கும் service-ஐ இணைப்பு சென்றடையவில்லை என்பதைக் குறிக்கிறது. container-க்குள் இருந்து அந்தப் பெயர் சரியாகத் தீர்மானிக்கப்படுகிறதா (resolve) என்பதை உறுதிப்படுத்தவும்:

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

ஒரு HTTP status code, network பாதை சரியாக உள்ளது என்பதை உறுதிப்படுத்துகிறது. பெயர் தீர்மானிப்பதில் பிழை (name resolution error) ஏற்பட்டால், service பெயர் சரியாக உள்ளதா என்று சரிபார்க்கவும். மேலும், இரண்டு container-களும் ஒரே Compose network-ல் இயங்குகின்றனவா என்பதையும் உறுதிப்படுத்தவும்.

Hardlinks உண்மையில் செயல்படுவதை உறுதிப்படுத்துதல்

Link count-ஐ சரிபார்க்கும் வரை இந்த அமைப்பை நம்ப வேண்டாம். ஒரு கோப்பு இறக்குமதி செய்யப்பட்ட பிறகு, தரவிறக்கம் செய்யப்பட்ட கோப்பையும் library கோப்பையும் ஒப்பிட்டுப் பார்க்கவும்:

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

முதல் எண் inode-ஐயும், இரண்டாவது எண் link count-ஐயும் குறிக்கும். ஒரே filesystem-ல், ஒன்றுக்கொன்று hardlink ஆக இருக்கும் இரண்டு கோப்புகள் ஒரே inode-ஐயும், குறைந்தது 2 என்ற link count-ஐயும் கொண்டிருக்கும்; கூடுதல் hardlinks இருந்தால் இந்த எண்ணிக்கை அதிகரிக்கும். வெவ்வேறு inode-கள் இருந்தால், அந்த கோப்புகள் ஒன்றுக்கொன்று hardlink இல்லை என்று பொருள், ஆனால் இது hardlink முயற்சி தோல்வியடைந்தது என்று அர்த்தமல்ல. Sonarr-ன் hardlink அமைப்பு முடக்கப்பட்டிருக்கும்போது, அது hardlink செய்ய முயலாமல் கோப்புகளை நகலெடுக்கும். Cross-filesystem hardlink தோல்விகள் Trace நிலையிலும், பிற hardlink விதிவிலக்குகள் Debug நிலையிலும் பதிவு செய்யப்படும், எனவே சாதாரண import logs-ல் இதற்கான விளக்கம் இருக்காது.

வட்டையும் (disk) கவனிக்கவும். ஒரு import நடக்கும்போது df -h /mnt/data மிகக் குறைவாகவே மாற வேண்டும், ஏனெனில் hardlink என்பது தரவை நகலெடுக்காமல் ஒரு பெயரை மட்டுமே சேர்க்கிறது.

எது உண்மையில் செயலிழக்கிறது

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 தேவை என்பதை நினைவில் கொள்ளவும்.

Host directory உருவாவதற்கு முன்பே container-ஐத் தொடங்கினால், root-க்குச் சொந்தமான directories உருவாகலாம். ஏனெனில், இல்லாத bind-mount directories-ஐ Docker தானாகவே உருவாக்கிவிடும். Stack-ஐ நிறுத்திவிட்டு, directory-ஐ chown செய்துவிட்டு, மீண்டும் தொடங்கவும்.

qBittorrent-லிருந்து ஒரு torrent-ஐ நீக்கும்போது library file-ம் மறைந்துவிட்டால், எந்தெந்த paths நீக்கப்பட்டன என்பதைச் சரிபார்க்க வேண்டும். பதிவிறக்கத்தை மட்டும் நீக்குவது, தனிப்பட்ட library copy-யையோ அல்லது hardlink-ஐயோ நீக்காது. உண்மையான hardlink இருக்கும்போது, ஒரு பெயரை நீக்கினாலும் மற்றொன்று அப்படியே இருக்கும். ஏனெனில், link count பூஜ்ஜியமாகும் போது மட்டுமே தரவு (data) நீக்கப்படும்.

நீங்கள் சேர்த்த media-வை விட disk வேகமாக நிரம்பினால், அது copy சிக்கலின் மிக மோசமான வடிவமாகும். கூடுதல் சேமிப்பகத்தை வாங்குவதற்கு முன், மேலே உள்ள stat சோதனையை இயக்கவும்.

இந்த stack-க்கு ஒரு VPS-லிருந்து தேவைப்படுபவை

மூன்று arr applications-ம் மிகக் குறைந்த வளங்களையே பயன்படுத்துகின்றன. அவை indexer-களை poll செய்கின்றன, சிறிய SQLite database-ல் எழுதுகின்றன, மற்றும் கோப்புகளை மறுபெயரிடுகின்றன. சுமை பிற இடங்களிலிருந்து வருகிறது. ஒரு download client பெரிய torrent-களைப் பதிவிறக்கும்போது disk input மற்றும் output-ஐ முழுமையாகப் பயன்படுத்துகிறது, அதே server-ல் media server transcoding செய்யும்போது CPU-ஐ எடுத்துக்கொள்ளும். Media கோப்புகளை அதிக throughput கொண்ட volume-ல் வையுங்கள், மேலும் server-ல் நீங்கள் முக்கியமாகக் கருதும் பிற பணிகள் ஏதேனும் இருந்தால், download client-க்கு bandwidth limit-ஐ அமைக்கவும். அந்த பிற பணிகளுக்குத் தேவையான வளங்களை முன்கூட்டியே திட்டமிடுங்கள்; headroom இருக்கும் என்று கருத வேண்டாம்: a self-hosted AFFiNE workspace என்பது ஒரு database-ஐக் கொண்ட நான்கு கூடுதல் containers ஆகும். அடிப்படை பயன்பாட்டிற்கு 2 GB RAM-ம், 10,000 வார்த்தைகளுக்கு மேலான ஆவணங்களுக்கு 4 GB RAM-ம் தேவை என AFFiNE பரிந்துரைக்கிறது. a self-hosted openGym workout tracker போன்ற ஒற்றை நோக்கம் கொண்ட பயன்பாட்டிற்கு, அதற்குத் தனி TLS-ஐ வழங்கவும். ஒரு வருட காலப் பயிற்சித் தரவுகளை அதில் சேமிக்கும் முன், அதன் தரவு கோப்புறை (data folder) எங்குள்ளது என்பதை உறுதிப்படுத்தவும். ஒரு web application, Postgres database மற்றும் background worker queue ஆகியவற்றைக் கொண்ட எந்தவொரு மென்பொருளும் AFFiNE-ன் வளத் தேவையை ஒத்திருக்கும். எனவே, a self-hosted Chatwoot support desk-ஐ இந்த server-ல் வைக்கலாமா அல்லது தனி server-ல் வைக்கலாமா என்பதை, import செய்யும் பாதியில் அதன் வரம்பை எட்டும் முன் முடிவு செய்யுங்கள். Bursty workloads-க்கு கூடுதல் கவனம் தேவை, ஏனெனில் அவற்றின் சராசரி பயன்பாட்டை விட உச்சகட்ட பயன்பாடே import செயல்பாட்டுடன் மோதும்: நீங்கள் a self-hosted OneCLI handing each person their own sandboxed agent-ஐப் பயன்படுத்த நினைத்தால், qBittorrent முழு வேகத்தில் இயங்கும்போது கிடைக்கும் இலவச வளங்களைச் சரிபார்க்கவும்; free -h ஒரு idle box-ல் காட்டும் அளவை வைத்து முடிவு செய்ய வேண்டாம்.

FAQ

Sonarr ஏன் கோப்புகளை hardlink செய்வதற்குப் பதிலாக நகலெடுக்கிறது?

Hardlinking முடக்கப்பட்டிருக்கலாம் அல்லது hardlink முயற்சி தோல்வியடைந்திருக்கலாம். Container-ன் பார்வையில் source மற்றும் destination வெவ்வேறு filesystems-ல் இருந்தால் இது நிகழும். /downloads மற்றும் /tv போன்ற இரண்டு தனித்தனி bind mounts, ஒரே host disk-லிருந்து வந்தாலும் அவை தனித்தனி mount points ஆகும்; hardlinks அவற்றைக்கடந்து செயல்பட முடியாது. ஒவ்வொரு container-லும் ஒரு பொதுவான தாய் கோப்பகத்தை (parent directory) /data என mount செய்து, downloads மற்றும் library ஆகியவற்றை அதற்குள் வைத்தால் link செய்வது சாத்தியமாகும். இரண்டு கோப்புகளிலும் stat -c '%i %h %n' கட்டளையைப் பயன்படுத்தி முடிவை உறுதிப்படுத்தவும்: ஒரே filesystem-ல் இருந்தால், அவை ஒரே inode-ஐயும் குறைந்தது 2 எண்ணிக்கையிலான link-களையும் கொண்டிருக்க வேண்டும்.

நான் எந்த PUID மற்றும் PGID-ஐப் பயன்படுத்த வேண்டும்?

Media tree-க்கு உரிமையாளராக இருக்கும் host account-ன் numeric id-ஐப் பயன்படுத்தவும். இதை id -u மற்றும் id -g மூலம் பெறலாம். புதிய Ubuntu VPS-ல் பொதுவாக இவை இரண்டிற்கும் 1000 என்றே இருக்கும். Stack-ல் உள்ள ஒவ்வொரு container-ம் ஒரே ஜோடியைப் பயன்படுத்த வேண்டும், இல்லையெனில் ஒரு application எழுதும் கோப்புகளை மற்றொன்றால் மாற்ற முடியாது. மதிப்புகளை மாற்றிய பிறகு, docker compose up -d --force-recreate மூலம் containers-ஐ மீண்டும் உருவாக்கி, chown -R மூலம் ஏற்கனவே உள்ள கோப்புகளைச் சரிசெய்யவும்.

இந்த web interfaces-ஐ இணையத்தில் வெளிப்படுத்த வேண்டுமா?

இல்லை, அவ்வாறு செய்யக்கூடாது. ஒவ்வொரு published port-ஐயும் Compose கோப்பில் 127.0.0.1-க்கு bind செய்யவும். பின்னர், SSH tunnel மூலமாகவோ அல்லது TLS (transport layer security) termination செய்து சொந்தமாக authentication சேர்க்கும் reverse proxy மூலமாகவோ interfaces-ஐ அணுகவும். Docker Engine 28.0.0 அல்லது அதற்குப் பிந்தைய பதிப்பு மற்றும் default bridge configuration-ல், VPN மூலம் மட்டும் 127.0.0.1-ல் publish செய்யப்பட்ட port-ஐ அணுக முடியாது, ஏனெனில் Docker அந்த port-ஐ host-லிருந்து மட்டுமே அணுகக்கூடியதாக மாற்றுகிறது. பழைய Docker பதிப்புகள் ஒரே local network segment-ல் உள்ள hosts-ஐ localhost-ல் publish செய்யப்பட்ட ports-ஐ அணுக அனுமதித்தன. VPN வழியாக நேரடி அணுகல் தேவைப்பட்டால், server-ன் VPN முகவரியில் ports-ஐ publish செய்யவும். பொதுவான interface-ல் நேரடியாகப் பதிப்பிடுவது ஆபத்தானது, ஏனெனில் Docker அதன் சொந்த firewall விதிகளைச் சேர்க்கிறது, மேலும் ufw deny விதியால் அந்த traffic-ஐத் தடுக்க முடியாது.

qBittorrent கடவுச்சொல்லை எங்கே கண்டறிவது?

LinuxServer.io image அதன் startup log-ல் admin பயனருக்கான தற்காலிக கடவுச்சொல்லை அச்சிடும். அதைப் படிக்க docker compose logs qbittorrent | grep -i password-ஐ இயக்கவும், பின்னர் Options மற்றும் Web UI பகுதிக்குச் சென்று நிரந்தர கடவுச்சொல்லை அமைக்கவும். நீங்கள் சொந்தமாக அமைக்கும் வரை, ஒவ்வொரு முறை restart செய்யும்போதும் புதிய தற்காலிக கடவுச்சொல் உருவாக்கப்படும்.

Jellyfin அதே கோப்புறைகளைப் பயன்படுத்த முடியுமா?

ஆம், அதுதான் இந்த அமைப்பின் நோக்கம். /mnt/data/media-ஐ உங்கள் media server-ல் /media என mount செய்யவும். அதன் libraries /media/Movies மற்றும் /media/Shows-ல் இருக்கும், அதே நேரத்தில் Sonarr மற்றும் Radarr ஆகியவை /data/media வழியாக அதே கோப்பகங்களில் எழுதும். Media server-க்கு அதே PUID மற்றும் PGID-ஐ வழங்கவும், அப்போதுதான் arr stack எழுதும் கோப்புகளை அதனால் படிக்க முடியும்.