EN
EN

הרשאות volume ב-Docker

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

כל volume מקבל כאן תת-תיקייה משלו, בשם ה-volume ב-Compose. השתמשו בתיקייה של compose.yaml (.) או בנתיב מלא כמו ‎/srv/n8n.

n8n (main) רץ כ-1000:1000 (משתמש node).

מנתוני המשתמש של n8n בקטלוג; המקורות בעמוד האפליקציה. מקורות והערות בעמוד של n8n

מה משתבש

‏Bind mount שומר את הבעלים שיש לתיקייה בשרת, והקונטיינר רואה רק מספרים. כש-./n8n-data לא בבעלות 1000:1000, התהליך לא יכול לכתוב אליו, רושם Permission denied ובדרך כלל יוצא.

בקונטיינרתיקייה בשרת
/home/node/.n8n./n8n-data
לפני שמריצים משהו
  • אל תשתמשו ב-chmod 777 (או chmod -R 777). הוא מאפשר לכל משתמש ותהליך בשרת לקרוא ולשנות את הנתונים, מסתיר את בעיית הבעלות האמיתית, וחלק מהאפליקציות מסרבות לעלות איתו (למשל PostgreSQL ומפתחות SSH).
  • ‏user: עובד רק אם ה-image תומך במשתמש שרירותי. בדקו בתיעוד של ה-image לפני שמשנים.

1. בדקו למי זה שייך (קריאה בלבד)

הפקודות האלה רק קוראות. השוו את הבעלים של כל נתיב ל-1000:1000.

  • ls -lnd ./n8n-dataקריאה בלבד הבעלים המספרי וההרשאות של התיקייה בשרת.
  • docker exec <project>-n8n-1 idקריאה בלבד המשתמש שהקונטיינר הרץ משתמש בו בפועל.
  • docker run --rm --entrypoint id docker.n8n.io/n8nio/n8n:2.42.6קריאה בלבד משתמש ברירת המחדל של ה-image, בקונטיינר חד-פעמי, כשהקונטיינר ממשיך לצאת.
  • idקריאה בלבד ה-uid וה-gid שלכם בשרת, בשביל user: ב-Compose.
check.sh
ls -lnd ./n8n-data
docker exec <project>-n8n-1 id
docker run --rm --entrypoint id docker.n8n.io/n8nio/n8n:2.42.6
id

2. תקנו

מומלץ העבירו את התיקייה לבעלות 1000:1000

עצרו את הקונטיינר, הריצו את אלה לכל נתיב, ואז הפעילו אותו שוב עם docker compose up -d. הנתיב מפורש: אל תריצו chown רקורסיבי על תיקיית אב.

משנה את השרת. הפקודות האלה משנות בעלות בשרת. קראו אותן, בדקו את הנתיב, ועצרו קודם את הקונטיינר.

  • sudo mkdir -p ./n8n-dataמשנה את השרת יוצרת את התיקייה אם היא חסרה.
  • sudo chown -R 1000:1000 ./n8n-dataמשנה את השרת מעבירה את התיקייה וכל מה שבתוכה לבעלות המשתמש של הקונטיינר.
fix.sh
sudo mkdir -p ./n8n-data
sudo chown -R 1000:1000 ./n8n-data

חלופה השתמשו ב-named volume במקום

כשלא צריך לערוך את הקבצים מהשרת, תנו ל-Docker לנהל את התיקייה: ‏named volume חדש מקבל את הבעלים שלו מה-image. העבירו אליו קודם את הנתונים הקיימים; שינוי הקובץ לבדו מתחיל עם volume ריק.

compose.yaml
services:
  n8n:
    volumes:
      - n8n-data:/home/node/.n8n
volumes:
  n8n-data:

חלופה הריצו את השירות כמשתמש שלכם

קבעו ב-user: את ה-uid:gid ש-id מדפיס, והעבירו את התיקייה לבעלות המשתמש הזה. עשו את זה רק כשהתיעוד של ה-image אומר שהוא רץ תחת כל משתמש: חלק מה-images צריכים משתמש ותיקיית בית משלהם.

משנה את השרת. הפקודות האלה משנות בעלות בשרת. קראו אותן, בדקו את הנתיב, ועצרו קודם את הקונטיינר.

  • sudo chown -R "$(id -u):$(id -g)" ./n8n-dataמשנה את השרת מעבירה את התיקייה לבעלות המשתמש שלכם, שהשירות ירוץ תחתיו.
fix.sh
sudo chown -R "$(id -u):$(id -g)" ./n8n-data
compose.yaml
services:
  n8n:
    user: "1000:1000"

מה הכלי עושה

הכלי מברר למה קונטיינר מקבל Permission denied בתיקיית הנתונים שלו ונותן את התיקון המדויק. קונטיינר רואה את הבעלים המספרי של תיקייה מחוברת, לא שם, ולכן תיקייה ששייכת ל-uid אחר, הרבה פעמים root אחרי mkdir ידני או שחזור גיבוי, לא ניתנת לכתיבה.

איך זה עובד

  1. באפליקציה מהקטלוג, המשתמש שכל קונטיינר רץ תחתיו והנתיבים שהוא כותב אליהם מגיעים מהנתונים המאומתים של הקטלוג (ops.runAs, עם מקורות בעמוד האפליקציה). ב-image משלכם, אתם מזינים את ה-uid ואת הנתיב.
  2. פקודות הבדיקה רק קוראות: ‏ls -lnd בשרת, ‏id בקונטיינר, וב-named volume גם ls בקונטיינר חד-פעמי שמחבר אותו לקריאה בלבד.
  3. התיקון תלוי בסוג ה-mount וב-rootless: ‏chown לתיקייה המדויקת, אותו chown מתוך ה-namespace של Docker במצב rootless, ‏user: ב-Compose כשה-image מאפשר, או named volume. פקודות שמשנות את השרת מסומנות.

דוגמה

‏n8n רץ כ-node, ‏1000:1000, וכותב אל ‎/home/node/.n8n. עם bind mount בתיקייה של compose.yaml ב-Docker רגיל, הבדיקה היא:

check.sh
ls -lnd ./n8n-data
docker exec <project>-n8n-1 id
docker run --rm --entrypoint id docker.n8n.io/n8nio/n8n:2.42.6
id

וכשהבעלים אינו 1000:1000, התיקון (כשהקונטיינר עצור) הוא:

fix.sh
sudo mkdir -p ./n8n-data
sudo chown -R 1000:1000 ./n8n-data

אל תשתמשו ב-chmod 777 (או chmod -R 777). הוא מאפשר לכל משתמש ותהליך בשרת לקרוא ולשנות את הנתונים, מסתיר את בעיית הבעלות האמיתית, וחלק מהאפליקציות מסרבות לעלות איתו (למשל PostgreSQL ומפתחות SSH).

מגבלות

  • ‏SELinux ו-AppArmor לא מכוסים: ב-Fedora, ‏RHEL ומערכות דומות bind mount עשוי לדרוש גם תווית ‎:z או ‎:Z, שהכלי לא כותב.
  • ‏Docker Desktop ב-Windows וב-macOS לא מכוסה; לשיתוף הקבצים שלו יש מודל הרשאות משלו.
  • שיתופי NFS ו-SMB יכולים למפות או לדחוס מזהים בצד השרת; ‏chown בצד הלקוח לא תמיד חל.
  • הקטלוג נותן את משתמש ברירת המחדל של ה-image. ‏user: או הגדרת PUID/PGID בקובץ שלכם משנים אותו.

קונטיינר שמופעל מחדש כל הזמן? עברו על האשף של לולאת ההפעלה מחדש

מתודולוגיה: איך מחושבים המספרים

מקורות

  1. Docker Engine: bind mounts
  2. Docker Engine: volumes
  3. Docker Engine: rootless mode
  4. Compose file reference: services, user
  5. chown(1)
  6. subuid(5)

עודכן

הצעד הבא

Docker Compose Generator

כלי ציבורי חינמי של אנרוק, חברה שבונה תשתיות מחשוב. מה אנרוק בונה