מערך arr שלם בקובץ Docker Compose אחד

מה אתם בונים

מחסנית (stack) של Docker Compose עבור arr מורכבת מארבע מכולות המנהלות ספריית מדיה: Prowlarr להגדרות אינדקסרים, Sonarr לסדרות, Radarr לסרטים, ו־qBittorrent כלקוח הורדות. הן מתקשרות זו עם זו ברשת ה-Compose לפי שם השירות, וחולקות עץ תיקיות אחד על המארח. ההתקנה קצרה. החלק שיקבע אם המחסנית תעבוד שנים או תגרום לבעיות מדי שבוע הוא מבנה ה-volumes, ולכן רוב המדריך הזה מתמקד בכך.

המחסנית אינה מוצאת עבורכם תוכן. Prowlarr מאחסן את האינדקסרים שתוסיפו לו, והבחירה באילו אינדקסרים להשתמש היא החלטה שלכם ואחריותכם המשפטית. מדריך זה מכסה את התשתית: משתמשים, נתיבים, הרשאות, תקשורת בין מכולות, והבדיקות שמוודאות שהכל עובד.

אם מעולם לא כתבתם קובץ Compose, קראו תחילה את יסודות Docker Compose עבור VPS. פוסט זה מניח ש־docker compose version כבר מדפיס משהו בשרת שלכם. השתמשו ב־Docker Engine בגרסה 28.0.0 או חדשה יותר: גרסאות ישנות מאפשרות למארחים באותו מקטע רשת מקומי להגיע לפורטים שפורסמו ל־localhost.

מדוע hardlinks נכשלים, ומדוע זהו לב העניין

כאשר Sonarr מסיים הורדה, הוא מייבא את הקובץ לספרייה שלכם. אם תיקיית ההורדות ותיקיית הספרייה נמצאות על אותה מערכת קבצים ו־hardlinking מופעל, Sonarr מנסה ליצור hardlink: שם שני המצביע על אותו מידע בדיסק. פעולה זו אינה צורכת שטח נוסף או זמן. הטורנט ממשיך לבצע seeding מהשם הישן, בעוד שרת המדיה שלכם קורא מהשם החדש.

אם שתי התיקיות נמצאות על מערכות קבצים שונות, ה-kernel אינו יכול ליצור את הקישור הזה. Sonarr חוזר לביצוע העתקה (copy). עונה בנפח 40 GB תופסת כעת 80 GB בדיסק ודורשת דקות ארוכות של פעולות קלט/פלט. Sonarr מתעד כשלים ב-hardlink בין מערכות קבצים ברמת Trace, וחריגות אחרות ב-hardlink ברמת Debug, לכן לוגים רגילים אינם מבטיחים הופעת הודעת שגיאה. בשרת VPS עם מכסת דיסק קבועה, כך אנשים נותרים ללא שטח פנוי תוך שבוע.

כאן טמונה המלכודת. בתוך מכולה (container), ה-bind mount מהווה גבול של מערכת קבצים. אם תבצעו mount ל-/mnt/data/torrents כ-/downloads ול-/mnt/data/media כ-/tv, גם אם שניהם נמצאים על אותו דיסק מארח, Sonarr רואה שני mount points נפרדים ואינו יכול לבצע hardlink ביניהם. התיעוד הרשמי של התמונה מבית LinuxServer.io מציין זאת במפורש: שימוש בנתיבים נפרדים כמו /downloads ו-/tv מקריב את היכולת לבצע hardlink.

הפתרון הוא mount יחיד. כל מכולה שניגשת למדיה מקבלת את אותו volume יחיד, /mnt/data:/data, וכל נתיב שבו הם משתמשים הוא תיקייה בתוכו. נקודת עיגון אחת, מערכת קבצים אחת, ו-hardlinks תקינים.

יצירת המשתמש, הקבוצה והתיקיות

המכולות כותבות קבצים באמצעות מזהה משתמש מספרי (UID), שנקבע על ידי PUID ו-PGID. השתמשו בחשבון שלכם כדי שתוכלו לקרוא ולערוך את הקבצים הללו דרך SSH ללא צורך ב-sudo.

id -u
id -g

שניהם בדרך כלל מציגים את 1000 בשרת VPS חדש עם Ubuntu. כעת בנו את עץ התיקיות. מקמו אותו על הכונן שבו נמצאים קובצי המדיה שלכם, ושמרו את כל העץ על אותו כונן.

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

ודאו שמדובר במערכת קבצים אחת לפני שתמשיכו:

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

שתי השורות חייבות להציג את אותו התקן מקור. שני התקנים שונים משמעותם שקישורים קשיחים (hardlinks) לא יעבדו, ללא קשר להגדרות שתבחרו בתצורת המכולה.

תיקיות הספרייה נקראות Movies ו-Shows בכוונה תחילה. אם אתם כבר מריצים את Jellyfin כשרת המדיה שלכם, בצעו mount ל-/mnt/data/media בתוך Jellyfin כ-/media, והספריות שלו ימוקמו ב-/media/Movies ו-/media/Shows, בדיוק במקום שבו המדריך ההוא מציב אותן.

קובץ הסביבה

שמרו את הערכים המשתנים בין שרת לשרת בתוך .env, לצד קובץ ה-Compose.

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

צרו את ~/arr/.env:

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

הגדירו את TZ לאזור הזמן שלכם, למשל Europe/Berlin. יישומי ה-arr מתזמנים משימות ומתייגים שורות לוג לפי אזור זה, לכן ערך שגוי יגרום לכל לוג להיות מבלבל בהמשך.

קובץ ה-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 זהה בשלושת הקונטיינרים שניגשים למדיה. Prowlarr לא מקבל אותו, כיוון ש-Prowlarr לעולם אינו פותח קובץ מדיה.

כל פורט אינטרנט ממופה ל-127.0.0.1, כך ש-Docker מפרסם אותו בכתובת ה-loopback בלבד. שימוש ב-8989:8989 פשוט יפרסם אותו בכל ממשק, וחוקי ה-firewall של Docker יעבירו את התעבורה הזו ישירות מעבר לחוק ufw deny. התנהגות זו מפתיעה משתמשים ללא הרף, והיא מוסברת ב-מדוע Docker מפרסם פורטים ישירות דרך ufw.

פורט 6881 מפורסם בכל הממשקים בכוונה תחילה. זהו פורט ההאזנה של ה-torrent, והוא חייב להיות נגיש לחיבורי peer נכנסים. אותה התנהגות של Docker חלה גם כאן, לכן אין צורך בחוק ufw עבורו, והוספת חוק כזה לא תשנה דבר. התיעוד של Docker, שנבדק ב-8 בנובמבר 2026, מציין שתעבורה לפורט מפורסם מנותבת לפני שהיא מגיעה ל-chains שבהן משתמש ufw, לכן ל-sudo ufw allow 6881 אין השפעה על פורט זה. Docker מפרסם אותו בכל ממשקי המארח ברגע שהקונטיינר עולה, וגם ufw deny לא יחסום אותו. אם תצטרכו אי פעם להגביל מי יכול להתחבר אליו, התיעוד של Docker מפנה לחוקים ב-chain מסוג DOCKER-USER עם ה-backend ברירת המחדל של iptables; ה-backend מסוג nftables דורש במקום זאת חוקים ב-table נפרד של nftables. השאירו את ufw עבור שירותים שאינם רצים ב-Docker, כגון SSH, וקראו את יסודות ה-firewall מסוג ufw עבור VPS אם כלי זה חדש לכם.

תיקיות התצורה נפרדות לכל יישום, ורק ה-volume של המדיה משותף. צרו אותן לפני ההפעלה הראשונה כדי שיהיו בבעלות המשתמש שלכם ולא בבעלות root:

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

כל ארבעת השירותים אמורים לקרוא את running. נכון ל-8 בנובמבר 2026, תמונות אלו מפורסמות ב-lscr.io והתגית latest עוקבת אחר ה-release היציב הנוכחי, לכן קבעו תגית גרסה ספציפית אם אתם מעדיפים ששדרוגים יהיו החלטה מודעת ולא הפתעה.

גישה מאובטחת לממשקי ה-Web

ממשקי ה-Web מוגדרים להאזנה ל-loopback בלבד. בצעו להם Forwarding דרך SSH מהמחשב האישי שלכם:

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 מאחורי Traefik עם תעודות TLS עבור מספר יישומים, או גשו לשרת דרך רשת VPN מסוג WireGuard שאתם מארחים בעצמכם. עם זאת, VPN לבדו אינו מספק גישה לפורטים אלו. תיעוד Docker, שנבדק ב-8 בנובמבר 2026, מציין כי בגרסאות Docker Engine 28.0.0 ומעלה, עם הגדרות ה-bridge כברירת מחדל, רק ה-host של Docker יכול לגשת לפורט שפורסם בכתובת localhost. כדי להשתמש ב-VPN, המשיכו להריץ את ה-SSH tunnel דרכו, או שנו את ה-bindings בקובץ ה-Compose מ-127.0.0.1 לכתובת ה-IP של השרת בממשק ה-VPN. אף אחד מיישומים אלו לא אמור להיות חשוף לאינטרנט הציבורי כשמגן עליו רק דף ההתחברות הפנימי שלו. אם בחרתם בנתיב של reverse proxy ואתם מעדיפים חשבון אחד לכל ארבעת הממשקים במקום לנהל ארבעה פרטי התחברות נפרדים, Authentik מספק פתרון Single Sign-On לאירוח עצמי ש-Traefik יכול לאכוף על כל בקשה באמצעות forward auth. ל-Sonarr ול-Radarr יש שני דגשים משלהם מאחורי proxy; לכן, לפני שתנתבו אותם דרך Traefik, קראו את המדריך להרצת Sonarr ו-Radarr מאחורי reverse proxy עבור הגדרות ה-Allowed Hosts שמונעות שגיאות Invalid Hostname, והסיבה לכך ש-/api חייב לדלג על דף ההתחברות.

qBittorrent מייצר סיסמת מנהל אקראית בהפעלה הראשונה ומדפיס אותה ללוג של ה-container. קראו אותה, ולאחר מכן שנו אותה בממשק ה-Web:

docker compose logs qbittorrent | grep -i password

אם תדלגו על שינוי הסיסמה, תיווצר סיסמה אקראית חדשה בכל אתחול, ותיאלצו לחזור ללוגים בכל פעם מחדש.

הגדרת הנתיבים בתוך כל יישום

ב-qBittorrent, פתחו את Options, עברו ל-Downloads, והגדירו את נתיב השמירה כברירת מחדל ל-/data/torrents. שמרו את התיקייה להורדות לא גמורות (incomplete-downloads) בתוך אותו עץ ספריות, למשל /data/torrents/incomplete. הורדה שמסתיימת מחוץ ל-/data לא תוכל לעבור קישור קשיח (hardlink) לספרייה עם קובץ ה-Compose הזה.

ב-Sonarr, פתחו את Settings, עברו ל-Media Management, והוסיפו את תיקיית השורש /data/media/Shows. ב-Radarr, תיקיית השורש היא /data/media/Movies. אלו הם נתיבים בתוך המכולה (container). הנתיב במארח (host) /mnt/data/media/Shows יידחה, כיוון שספרייה זו אינה קיימת מנקודת המבט של המכולה.

בשני היישומים, Sonarr ו-Radarr, פתחו את Settings, עברו ל-Download Clients, והוסיפו את qBittorrent. המארח (host) הוא qbittorrent והפורט הוא 8080. שם השירות מתפקד כשם מארח (hostname) מכיוון ש-Compose מציב את כל ארבע המכולות על רשת אחת עם שירות DNS פנימי. אל תשתמשו ב-localhost כאן: בתוך המכולה של Sonarr, ה-localhost הוא Sonarr עצמו.

השאירו את Remote Path Mappings ריק. תכונה זו קיימת כדי לתרגם נתיב שמדווח לקוח ההורדות לנתיב שהיישום מסדרת ה-arr יכול לראות. עם נקודת עיגון (mount) משותפת אחת של /data, שני היישומים כבר מסונכרנים על כל נתיב, וזו הסיבה השנייה לכך שמבנה זה מצדיק את המאמץ.

חיבור Prowlarr ל-Sonarr ול-Radarr

Prowlarr דוחף הגדרות של אינדקסרים ליישומים האחרים, כך שניתן להגדיר אינדקסר פעם אחת במקום פעמיים. לשם כך הוא זקוק למפתח API (ממשק תכנות יישומים) מכל אחד מהם.

ב-Sonarr, פתחו את Settings, לאחר מכן את General, והעתיקו את מפתח ה-API. ב-Prowlarr, פתחו את Settings, לאחר מכן את Apps, הוסיפו יישום Sonarr, ומלאו שלושה שדות. ה-Prowlarr Server הוא http://prowlarr:9696. ה-Sonarr Server הוא http://sonarr:8989. ה-API Key הוא הערך שהעתקתם. לחצו על Test. תוצאה ירוקה מעידה על כך ש-Prowlarr הגיע ל-Sonarr דרך רשת ה-Compose. חזרו על הפעולה עם Radarr בכתובת http://radarr:7878.

תוצאה אדומה המציינת שהחיבור נדחה (connection refused) משמעותה שהחיבור לא הגיע לשירות המאזין בכתובת ובפורט שהוגדרו. ודאו שהשם מתורגם (resolves) מתוך המכולה:

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

קוד סטטוס HTTP מוכיח שמסלול הרשת תקין. שגיאת תרגום שמות (name resolution error) משמעותה ששם השירות לא תורגם; בדקו את האיות שלו וודאו ששתי המכולות רצות על אותה רשת Compose.

אימות פעולת hardlinks

אל תסתמך על ההגדרה עד שלא תראה את מונה הקישורים (link count). לאחר ייבוא פריט אחד, השווה בין הקובץ שהורד לבין הקובץ בספרייה:

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

המספר הראשון הוא ה-inode והשני הוא מונה הקישורים. באותה מערכת קבצים, שני קבצים שהם hardlinks זה לזה יציגו את אותו inode ומונה קישורים של לפחות 2; hardlinks נוספים יגדילו את המונה הזה. inodes שונים מעידים על כך שהקבצים אינם hardlinks זה לזה, אך אין בכך הוכחה לכך שניסיון יצירת hardlink נכשל. Sonarr גם מבצע העתקה ללא ניסיון ליצור hardlink כאשר ההגדרה הרלוונטית מושבתת. כשלים ביצירת hardlink בין מערכות קבצים שונות מתועדים ברמת Trace, וחריגות אחרות הקשורות ל-hardlinks מתועדות ברמת Debug, לכן לוגים רגילים של ייבוא לא תמיד יספקו הסבר.

עקוב גם אחר הדיסק. df -h /mnt/data כמעט ולא אמור להשתנות בעת ביצוע ייבוא, מכיוון ש-hardlink מוסיף שם בלבד ולא נתונים.

מה גורם לתקלות בפועל

שגיאות הרשאה בעת ייבוא מצביעות על כך ש־user id של המכולה אינו מורשה לכתוב לתיקיית הספרייה. ההודעה היא Access to the path ... is denied. בדקו באמצעות ls -ln /mnt/data/media שה־owner id תואם ל־PUID שלכם, וזכרו שתיקיות דורשות את ה־execute bit כדי שהמכולה תוכל לגשת אליהן.

תיקיות בבעלות root עלולות להיווצר אם המכולה הופעלה לפני שתיקיית ה־host הייתה קיימת, כיוון ש־Docker יוצר אוטומטית תיקיות bind-mount חסרות. עצרו את ה-stack, בצעו chown לתיקייה, והפעילו אותה מחדש.

מחיקת טורנט מ־qBittorrent והיעלמות הקובץ מהספרייה מחייבת בדיקה של הנתיבים שנמחקו; מחיקת ההורדה בלבד אינה מסירה עותק נפרד או hardlink בספרייה. בשימוש ב־hardlink תקין, הסרת שם אחד מותירה את השני שלם, כיוון שהנתונים משוחררים רק כאשר מונה הקישורים מגיע לאפס.

דיסק שמתמלא מהר יותר מהמדיה שהוספתם הוא בעיית העתקה בצורתה היקרה ביותר. הריצו את בדיקת ה-stat לעיל לפני שאתם רוכשים שטח אחסון נוסף.

מה ה-stack הזה דורש מ-VPS

שלושת יישומי ה-arr הם קלים. הם מבצעים polling לאינדקסרים, כותבים למסד נתונים קטן מסוג SQLite, ומשנים שמות של קבצים. העומס מגיע ממקורות אחרים. לקוח הורדות מנצל את רוחב הפס של ה-I/O בדיסק בעת הורדת טורנטים גדולים, ושרת מדיה שמבצע transcoding לווידאו על אותו שרת יצרוך את ה-CPU. שמרו את המדיה על כונן עם תפוקה (throughput) ממשית, והגדירו הגבלת רוחב פס בלקוח ההורדות אם השרת מבצע פעולות נוספות שחשובות לכם. תכננו תקציב משאבים בנפרד עבור אותן פעולות, במקום להניח שיש מספיק מרווח פעולה: סביבת עבודה עצמאית של AFFiNE היא עוד ארבע מכולות עם מסד נתונים מאחוריהן, ו-AFFiNE ממליצה על 2 GB של RAM לשימוש בסיסי ו-4 GB למסמכים מעל 10,000 מילים. עבור שירות בעל מטרה יחידה כמו מעקב אימונים עצמאי של openGym, הקצו לו TLS משלו ודעו היכן נמצאת תיקיית הנתונים שלו לפני שאתם מפקידים בידיו היסטוריית אימונים של שנה. כל מה שמריץ יישום אינטרנט, מסד נתונים Postgres ותור משימות רקע נמצא קרוב יותר לצד של AFFiNE בטווח הזה, לכן החליטו האם מוקד תמיכה עצמאי של Chatwoot שייך לשרת הזה או לשרת נפרד לפני שתגלו את המגבלה באמצע תהליך ייבוא. עומסי עבודה מתפרצים (bursty) דורשים זהירות רבה עוד יותר, כיוון שהשיא שלהם, ולא הממוצע, הוא זה שמתנגש עם תהליך ייבוא: אם אתם שוקלים להריץ סוכן מבודד לכל משתמש של OneCLI, בדקו את נתוני הגודל המפורסמים שלו מול מה שבאמת פנוי בזמן ש-qBittorrent רץ במלוא העוצמה, ולא מול מה ש-free -h מציג בשרת במצב המתנה.

FAQ

מדוע Sonarr מעתיק קבצים במקום ליצור קישורים קשיחים (hardlinks)?

הדבר קורה מכיוון שקישורים קשיחים מושבתים, או מכיוון שניסיון היצירה נכשל, לרבות במקרים שבהם המקור והיעד נמצאים על מערכות קבצים שונות מנקודת המבט של המכולה. שני חיבורי mount נפרדים, כגון /downloads ו-/tv, הם נקודות עיגון נפרדות גם כאשר שניהם מגיעים מאותו כונן מארח, וקישורים קשיחים אינם יכולים לחצות ביניהם. בצעו mount לתיקיית אב אחת כ-/data בכל מכולה, מקמו את ההורדות ואת הספרייה בתוכה, והקישור יתאפשר. אשרו את התוצאה באמצעות stat -c '%i %h %n' על שני הקבצים: על אותה מערכת קבצים, עליהם להציג את אותו inode ומונה קישורים של לפחות 2.

באילו PUID ו-PGID עלי להשתמש?

השתמשו במזהה המספרי של חשבון המארח שבבעלותו נמצא עץ המדיה, אותו ניתן לקבל באמצעות id -u ו-id -g. בשרת VPS מסוג Ubuntu חדש, הערך הוא בדרך כלל 1000 עבור שניהם. כל מכולה ב-stack חייבת להשתמש באותו זוג, אחרת יישום אחד יכתוב קבצים שאחר לא יוכל לשנות. לאחר שינוי הערכים, צרו מחדש את המכולות באמצעות docker compose up -d --force-recreate ותקנו את הקבצים הקיימים באמצעות chown -R.

האם עלי לחשוף את ממשקי ה-web האלה לאינטרנט?

לא, ואין לעשות זאת. קשרו כל פורט מפורסם ל-127.0.0.1 בקובץ ה-Compose, ולאחר מכן גשו לממשקים דרך מנהרת SSH או דרך reverse proxy בשרת שמבצע TLS termination (אבטחת שכבת תעבורה) ומוסיף אימות משלו. עם Docker Engine 28.0.0 או גרסה חדשה יותר ותצורת ה-bridge המוגדרת כברירת מחדל, VPN לבדו לא יוכל להגיע לפורט שמפורסם ב-127.0.0.1, מכיוון ש-Docker הופך פורט מפורסם זה לנגיש מהמארח עצמו בלבד. גרסאות Docker ישנות יותר מאפשרות למארחים באותו מקטע רשת מקומי להגיע לפורטים שמפורסמים ל-localhost. אם ברצונכם בגישה ישירה דרך VPN, פרסמו את הפורטים בכתובת ה-VPN של השרת במקום זאת. פרסום שלהם ישירות על הממשק הציבורי גרוע מכפי שהוא נראה, מכיוון ש-Docker מחדיר חוקי firewall משלו וחוק ufw מסוג deny לא יעצור תעבורה זו.

היכן אמצא את הסיסמה של qBittorrent?

ה-image של LinuxServer.io מדפיס סיסמה זמנית עבור המשתמש admin בלוג העלייה שלו. הריצו את docker compose logs qbittorrent | grep -i password כדי לקרוא אותה, ולאחר מכן הגדירו סיסמה קבועה תחת Options ו-Web UI. סיסמה זמנית חדשה נוצרת בכל אתחול עד שתגדירו סיסמה משלכם.

האם Jellyfin יכול להשתמש באותן תיקיות?

כן, וזו בדיוק המטרה של המבנה הזה. בצעו mount ל-/mnt/data/media לתוך שרת המדיה שלכם כ-/media, והספריות שלו יימצאו ב-/media/Movies ו-/media/Shows, בעוד ש-Sonarr ו-Radarr כותבים לאותן תיקיות בדיוק דרך /data/media. העניקו לשרת המדיה את אותם PUID ו-PGID כדי שיוכל לקרוא את מה שה-arr stack כותב.