أين يخزن Nextcloud في Docker ملفاته؟

Where Nextcloud in Docker stores files

Nextcloud in Docker stores files in a data directory inside the container, and the real location on your server is whichever volume or bind mount you attached to it. With the linuxserver.io image, lscr.io/linuxserver/nextcloud, user files live in /data, and the Nextcloud installation with its config.php lives in /config. Both of those are container paths. One command prints the host path behind them, and the rest of this guide covers the harder half of the question: everything the data directory does not hold.

Pin the image tag. Paths belong to an image rather than to Nextcloud, and a floating tag can move under you. As of August 2026 the current stable tag for this image is 34.0.3.

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:34.0.3
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - nextcloud_config:/config
      - nextcloud_data:/data
    ports:
      - 443:443
    restart: unless-stopped

  nextcloud-db:
    image: mariadb:11.8
    container_name: nextcloud-db
    environment:
      - MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${NEXTCLOUD_DB_PASSWORD}
    volumes:
      - nextcloud_db:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_config:
  nextcloud_data:
  nextcloud_db:

The two passwords come from a .env file next to the compose file, so they stay out of the compose file itself. That is three volumes in the answer, and only one of them holds user files.

Those container paths come from the documentation for that one image. A different Nextcloud image lays out its filesystem differently and keeps the installation under its own web root, so a path copied from a forum post is a guess. Read the truth from the container you are running.

docker inspect nextcloud

The Mounts section of that output lists every mount, with Source on the host side and Destination on the container side. That listing answers the question for your setup, whichever image you chose.

كيف أعثر على مسار المضيف الفعلي خلف وحدة التخزين؟

تُدار وحدة التخزين المسماة بواسطة Docker، لذلك لا تختار مسارها. بل تطلبه من Docker.

docker volume ls
docker volume inspect nextcloud_nextcloud_data

الاسم مهم. يضيف Docker Compose اسم المشروع إلى أسماء وحدات التخزين. ويكون اسم المشروع افتراضياً هو اسم الدليل الذي يحتوي على ملف Compose، لذلك توجد وحدة التخزين المكتوبة بصيغة nextcloud_data في الملف عادةً على القرص باسم nextcloud_nextcloud_data. يعرض docker volume ls الأسماء الفعلية. ويكون خرج الفحص كما يلي بعد اختصاره:

[
    {
        "CreatedAt": "2026-08-18T09:12:44Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/nextcloud_nextcloud_data/_data",
        "Name": "nextcloud_nextcloud_data",
        "Scope": "local"
    }
]

تمثل Mountpoint الإجابة. اقرأها من الأمر بدلاً من افتراضها، لأن المسار قد يتغير. في Docker الذي يعمل دون root، يوجد جذر بيانات Docker بالكامل داخل الدليل الرئيسي للمستخدم الذي يشغّل daemon، لذلك يبدأ هذا المسار من موقع آخر.

يزيل الربط المباشر السؤال. اكتب - /srv/nextcloud/data:/data في ملف Compose، وسيكون مسار المضيف هو المسار الذي أدخلته، ويعرضه docker inspect بوصفه Source. ويؤثر هذا الاختيار في أكثر من المسار، لأن وحدات التخزين المسماة والربط المباشر تتصرفان بشكل مختلف فيما يتعلق بالملكية والنسخ الاحتياطية.

لماذا لا يُعد مجلد البيانات نسخة احتياطية

يسرد دليل Nextcloud خمسة عناصر يجب أن تحتفظ بها النسخة الاحتياطية: مجلد الإعدادات، ومجلد التطبيقات المخصصة، ومجلد البيانات، ومجلد السمات، وقاعدة البيانات. في هذه الصورة، توجد مجلدات الإعدادات والتطبيقات والسمات جميعها ضمن /config، بينما تعمل قاعدة البيانات في حاوية مستقلة لها volume خاص بها. إذا نسخت /data وحده، فأنت تحفظ الجزء الأقل أهمية من المشكلة.

قاعدة البيانات مهمة لأن واجهة الويب لا تعرض محتويات دليل مباشرة. بل تعرض صفوفاً من ذاكرة التخزين المؤقت للملفات، ولذلك يطلب منك الدليل تشغيل فحص بعد نسخ الملفات يدوياً إلى مجلد البيانات. إذا استعدت /data بجوار قاعدة بيانات فارغة، فستحصل على وحدات بايت بلا فهرس: لا مستخدمين، ولا مشاركات، ولا شيء في قائمة الملفات. وإذا استعدت قاعدة البيانات بجوار /data فارغ، فسيشير كل صف إلى ملف لم يعد موجوداً.

يحتوي config.php على بيانات اعتماد قاعدة البيانات والنطاقات الموثوقة. كما يحتوي على معرّف المثيل، وهو اسم مجلد بيانات التطبيق داخل مجلد البيانات. استعلم من المثيل قيد التشغيل بدلاً من الاعتماد على أي من القيمتين المحفوظتين في الذاكرة.

docker exec -it nextcloud occ config:system:get datadirectory
docker exec -it nextcloud occ config:system:get instanceid

يطبع الأمر الأول مجلد البيانات الذي يستخدمه هذا المثيل فعلياً، وهو /data هنا. تتضمن هذه الصورة غلافاً باسم occ على المسار، لذا شغّله مباشرة عبر docker exec. لا تنسخ الصيغة الأطول sudo وphp occ من دليل Nextcloud، لأنها مخصّصة لتثبيت يعمل خارج حاوية.

ما الذي يملأ وحدة تخزين البيانات بصمت؟

توجد المعاينات وسجل كل مستخدم في وحدة التخزين نفسها التي تحتوي على الملفات، ولا يظهر أيٌّ منهما في حجم التخزين الذي يراه المستخدم في واجهة الويب.

• المعاينات هي صور مصغرة مُنشأة. توجد في مجلد بيانات التطبيق داخل دليل البيانات، ويُسمّى هذا المجلد appdata_ متبوعاً بمعرّف المثيل.
• تبقى الملفات المحذوفة في سلة المحذوفات. تكون قيمة trashbin_retention_obligation الافتراضية هي auto، ما يعني الاحتفاظ بها لمدة 30 يوماً وإزالتها بعد ذلك فقط عند الحاجة إلى مساحة. تظل الملفات المحذوفة محسوبة ضمن حصة المستخدم، وعند تجاوز الحصة يتجاهل النظام إعداد الاحتفاظ ويقلّص سلة المحذوفات حتى تعود الحصة إلى الحد المسموح.
• تبقى الإصدارات القديمة أيضاً. تكون قيمة versions_retention_obligation الافتراضية هي auto. لا يستخدم تطبيق Versions أكثر من 50% من المساحة المتاحة حالياً للمستخدم، وعند تنظيف الإصدارات يحذف أقدم الإصدارات أولاً مع الاحتفاظ بأحدث إصدارين. ولا يُحذف أبداً إصدار سمّاه المستخدم يدوياً.

قِس الاستخدام قبل حذف أي شيء.

docker exec -it nextcloud sh -c 'du -sh /data/*'
docker exec -it nextcloud sh -c 'du -sh /data/appdata_*'

يعرض السطر الأول رقماً واحداً لكل مجلد مستخدم، بالإضافة إلى مجلد بيانات التطبيق. إذا كان حجم بيانات التطبيق كبيراً، فالمعاينات هي السبب. أوامر التنظيف أدناه موثّقة، وكل واحد منها يحذف البيانات عمداً.

docker exec -it nextcloud occ trashbin:cleanup --all-users
docker exec -it nextcloud occ versions:cleanup alice
docker exec -it nextcloud occ preview:cleanup

يزيل preview:cleanup كل معاينة مُنشأة، ثم ينشئ Nextcloud المعاينات مجدداً عندما يفتح المستخدمون تلك الملفات، لذلك تعود المساحة للاستهلاك تدريجياً ويتحمل CPU كلفة ذلك. إذا كانت وحدة التخزين جزءاً من مشكلة أوسع في القرص، فعادةً ما تكون الصور القديمة وذاكرة التخزين المؤقت القديمة لعمليات البناء هي الجزء الآخر.

لماذا لا تظهر الملفات التي أنسخها إلى المضيف في Nextcloud؟

لأن Nextcloud يقرأ ذاكرة التخزين المؤقت للملفات من قاعدة البيانات، وليس من الدليل. أنشأت عملية النسخ ملفاً على القرص من دون صف مطابق في قاعدة البيانات، لذلك لا تملك واجهة الويب أي ملف لعرضه. يذكر الدليل هذه الحالة تحديداً: يجب إجراء فحص بعد نسخ الملفات مباشرةً إلى دليل البيانات.

docker exec -it nextcloud occ files:scan --path="/alice/files/Photos"
docker exec -it nextcloud occ files:scan --unscanned -v
docker exec -it nextcloud occ files:scan --all

توضح الوسيطة --path أيضاً البنية داخل دليل البيانات: يملك كل مستخدم مجلداً يحمل اسم المستخدم، ويحتوي files بداخله على ما يراه المستخدم في واجهة الويب. افحص مساراً واحداً عندما تعرف مكان الملفات. تمر الوسيطة --all على جميع المستخدمين، وقد تستغرق وقتاً طويلاً في مثيل كبير. لا تلمس --unscanned إلا الملفات المعلَّمة على أنها لم تُفحص بالكامل بعد. تطبع -v كل ملف أثناء معالجته، وهذا يوضح الفرق بين أمر يبدو متوقفاً وأمر يمكنك مراقبته.

تحدد الملكية ما إذا كان الفحص كافياً. إذا تعذر على مستخدم الحاوية الكتابة إلى ملف، فستتم فهرسته، ثم تفشل عملية نقله. لذلك تبدو القائمة صحيحة، بينما تفشل إعادة التسمية أو عملية الحذف من واجهة الويب.

لماذا تفشل عمليات الكتابة بعد ضبط PUID وPGID؟

لأن kernel يقارن الأرقام، لا الأسماء. يحدد PUID وPGID معرّف المستخدم الرقمي (uid) ومعرّف المجموعة الرقمي (gid) اللذين تعمل بهما العملية داخل الحاوية. ويحمل كل ملف على المضيف أيضاً معرّف مالك رقمي. عندما يختلف الرقمان، تُرفض عملية الكتابة، مهما بدت الأسماء متطابقة على أي من الجانبين.

docker exec -it nextcloud id abc
sudo ls -ln /var/lib/docker/volumes/nextcloud_nextcloud_data/_data

يعرض id abc معرّفي uid وgid اللذين تستخدمهما الحاوية فعلياً، وهما القيمتان اللتان ضبطتهما في PUID وPGID. ويعرض ls -ln المالكين بصيغة رقمية، وهنا تكمن أهمية -n: إذ يترجم ls -l العادي هذه الأرقام باستخدام قائمة المستخدمين الخاصة بالمضيف، ويعرض اسماً لا يعني شيئاً داخل الحاوية. قارن الرقمين.

اختبر الكتابة بعد ذلك بدلاً من التخمين.

docker exec -u abc -it nextcloud touch /data/writetest

يؤكد Permission denied الذي يسمّي /data نجاح العملية. أصلح الملكية من داخل الحاوية، ثم شغّل الاختبار نفسه مرة أخرى.

docker exec -u 0 -it nextcloud chown -R abc:abc /data
docker exec -u abc -it nextcloud touch /data/writetest
docker exec -u abc -it nextcloud rm /data/writetest

نفّذ ذلك من الداخل لسبب محدد. في Docker الذي يعمل دون root، تُربط معرّفات المستخدمين داخل الحاوية بنطاق المعرّفات الفرعي في /etc/subuid، ولذلك ينتمي uid 1000 داخل الحاوية إلى uid أعلى بكثير على المضيف. عندئذ يعيّن chown 1000:1000 المنفّذ على المضيف مالكاً لا تستطيع الحاوية استخدامه، فتستمر عملية الكتابة في الفشل. يؤدي تشغيل chown داخل الحاوية إلى استخدام الربط نفسه الذي تستخدمه عملية Nextcloud، ولذلك تتطابق الأرقام بحكم آلية الربط. ولهذا السبب أيضاً يجب أن يتطابق PUID وPGID مع المالك على القرص قبل أن تبدأ في تصحيح أي مشكلة أخرى.

كيف تنشئ نسخة احتياطية بحيث تنجح عملية الاستعادة فعلياً؟

خذ قاعدة البيانات والمجلدات من اللحظة نفسها. يوقف وضع الصيانة عمليات تسجيل الدخول، لذلك لا يصل أي رفع بين تفريغ قاعدة البيانات ونسخ الملفات.

docker exec -it nextcloud occ maintenance:mode --on
docker exec nextcloud-db mariadb-dump --single-transaction -u nextcloud -p"$NEXTCLOUD_DB_PASSWORD" nextcloud > nextcloud-sqlbkp.sql
docker run --rm -v nextcloud_nextcloud_data:/data:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-data.tgz -C /data .
docker run --rm -v nextcloud_nextcloud_config:/config:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-config.tgz -C /config .
docker exec -it nextcloud occ maintenance:mode --off

لاحظ ما لا يتضمنه سطر التفريغ: العلامة -t. يعيد TTY كتابة نهايات الأسطر، ويصبح تفريغ SQL الذي مرّ عبره تالفاً بطريقة لا تكتشفها إلا أثناء الاستعادة. لاحظ أيضاً أن كلمة المرور الموجودة في سطر الأوامر تظهر في مخرجات ps أثناء تشغيل الأمر، لذلك اقرأها من ملف .env إلى shell بدلاً من كتابتها. تأتي صور قواعد البيانات الأقدم مع mysqldump بدلاً من mariadb-dump، ويوثّق الدليل كليهما.

للاستعادة، حمّل التفريغ إلى قاعدة بيانات فارغة، وفك ضغط الأرشيفين إلى volumes جديدة، وشغّل الحاويات، ثم عطّل وضع الصيانة. إذا كان المجلدان والتفريغ من لحظتين مختلفتين، فلن تتطابق ذاكرة التخزين المؤقت للملفات مع القرص، ولا تصلح occ files:scan --all إلا أحد الاتجاهين. فهي تعثر على الملفات الموجودة من دون صف مقابل. ولا تستطيع استعادة ملف يشير إليه صف ولم يعد موجوداً.

احتفظ بالنتيجة خارج الخادم. فالنسخة الموجودة داخل VPS نفسه تُفقد مع VPS، ولذلك يجب أن تكون استخدام restic مع مستودع خارج الخادم جزءاً من هذه العملية، كما أن لقطة موفّر الخدمة أداة مختلفة عن النسخة الاحتياطية. إذا كنت لا تزال تبني المكدس، فإن تثبيت Nextcloud كاملاً على VPS يشرح إعداد Reverse Proxy وشهادة TLS (أمان طبقة النقل) اللذين لا يغطيهما هذا الدليل.

FAQ

أين يوجد دليل بيانات Nextcloud داخل حاوية Docker؟

في صورة linuxserver.io يوجد الدليل في /data داخل الحاوية، ويكون التثبيت باستخدام config.php ضمن /config. هذه مسارات داخل الحاوية. لمعرفة المسار على المضيف، شغّل docker inspect nextcloud واقرأ قيمة Source ضمن القسم Mounts، أو شغّل docker volume inspect على volume واقرأ Mountpoint. تستخدم صور Nextcloud الأخرى مسارات مختلفة داخل الحاوية، لذلك راجع وثائق الوسم الذي ثبّتَّه، وتأكد باستخدام docker exec -it nextcloud occ config:system:get datadirectory.

لماذا لا تظهر الملفات التي أنسخها إلى volume في Nextcloud؟

يعرض Nextcloud السجلات من ذاكرة التخزين المؤقت للملفات في قاعدة البيانات، ولا يقرأ الدليل مباشرة. لذلك لا يملك الملف الذي يصل من دون المرور عبر Nextcloud سجلاً، ويبقى غير مرئي. شغّل docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" لمجلد واحد، أو occ files:scan --all لكل مستخدم. إذا ظهرت الملفات ثم تعذّر نقلها أو حذفها، فالسبب هو الملكية: يجب أن يتمكن مستخدم الحاوية من الكتابة إليها.

هل تكفي نسخة من data volume لاستعادة Nextcloud؟

لا. يحتوي data volume على محتوى الملفات. وتحتوي قاعدة البيانات على فهرس الملفات والمستخدمين والمشاركات، بينما يحتوي config.php على بيانات اعتماد قاعدة البيانات ومعرّف المثيل. تتطلب الاستعادة العاملة مجلد البيانات، ومجلد الإعدادات، وقاعدة البيانات، ومجلدي التطبيقات المخصصة والقالب إذا كنت تستخدمهما. خذها كلها من اللحظة نفسها، لأن قاعدة البيانات الأحدث من الملفات قد تشير إلى ملفات غير موجودة.

لماذا أصبح data volume أكبر بكثير من الملفات التي يراها المستخدمون؟

توجد المعاينات والملفات المحذوفة والإصدارات القديمة في volume نفسه، ولا يظهر أي منها في الرقم الذي يراه المستخدم. قِس الحجم باستخدام docker exec -it nextcloud sh -c 'du -sh /data/*'. يحتفظ سلة المحذوفات بالملفات المحذوفة لمدة 30 يوماً افتراضياً، ولا يحذفها قبل ذلك إلا عند الحاجة إلى مساحة، كما يمكن لتطبيق Versions استخدام ما يصل إلى نصف المساحة الحرة المتاحة حالياً للمستخدم. احذفها باستخدام occ trashbin:cleanup --all-users وocc versions:cleanup alice وocc preview:cleanup، وتوقع أن تكبر المعاينات مجدداً مع فتح المستخدمين لملفاتهم.

هل يمكنني نقل دليل بيانات Nextcloud إلى قرص آخر؟

ثبّت الموقع الجديد على مسار الحاوية نفسه بدلاً من تغيير المسار الذي يعرفه Nextcloud. أوقف الحاوية، وانسخ المحتويات القديمة إلى القرص الجديد مع الحفاظ على الملكية باستخدام (cp -a أو rsync -aAX)، ثم وجّه volume أو bind mount إلى الموقع الجديد في ملف compose، وبعد ذلك شغّل الحاوية مجدداً. سيظل Nextcloud يرى /data، لذلك لا يلزم تغيير أي سجل في قاعدة البيانات. تحقّق باستخدام docker exec -it nextcloud occ config:system:get datadirectory ثم أجرِ عملية رفع تجريبية واحدة.