Docker में Nextcloud डेटा फाइलें कहाँ स्टोर होती हैं

Nextcloud in Docker फाइलें कहाँ स्टोर करता है

Docker में Nextcloud फाइलें container के अंदर एक data directory में स्टोर करता है, और आपके सर्वर पर इनका वास्तविक स्थान वह volume या bind mount होता है जिसे आपने इससे attach किया है। linuxserver.io image के साथ, lscr.io/linuxserver/nextcloud, उपयोगकर्ता की फाइलें /data में रहती हैं, और Nextcloud installation अपने config.php के साथ /config में रहता है। ये दोनों container paths हैं। एक command इनके पीछे का host path दिखा देती है, और इस guide का बाकी हिस्सा प्रश्न के कठिन भाग को कवर करता है: वह सब कुछ जो data directory में नहीं होता।

Image tag को pin करें। Paths Nextcloud के बजाय किसी image से संबंधित होते हैं, और एक floating tag आपके नियंत्रण के बिना बदल सकता है। अगस्त 2026 तक इस image के लिए वर्तमान stable tag 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:

दोनों passwords compose file के बगल में स्थित एक .env file से आते हैं, इसलिए वे स्वयं compose file से बाहर रहते हैं। उत्तर में ये तीन volumes हैं, और उनमें से केवल एक में उपयोगकर्ता की फाइलें होती हैं।

वे container paths उस एक image के documentation से आते हैं। एक अलग Nextcloud image अपने filesystem को अलग तरह से व्यवस्थित करती है और installation को अपने स्वयं के web root के अंतर्गत रखती है, इसलिए forum post से copy किया गया path केवल एक अनुमान है। आप जो container चला रहे हैं, उससे सच्चाई जानें।

docker inspect nextcloud

उस output का Mounts section हर mount को सूचीबद्ध करता है, जिसमें host side पर Source और container side पर Destination होता है। वह सूची आपके setup के लिए प्रश्न का उत्तर देती है, चाहे आपने कोई भी image चुनी हो।

वॉल्यूम के पीछे वास्तविक होस्ट पाथ कैसे पता करें?

Named volume को Docker द्वारा मैनेज किया जाता है, इसलिए आप उसका पाथ खुद तय नहीं करते हैं। आप इसके बारे में जानकारी मांगते हैं।

docker volume ls
docker volume inspect nextcloud_nextcloud_data

नाम महत्वपूर्ण है। Docker Compose वॉल्यूम के नामों के आगे प्रोजेक्ट का नाम जोड़ देता है, जो डिफ़ॉल्ट रूप से उस डायरेक्टरी का नाम होता है जिसमें आपकी compose फाइल मौजूद है। इसलिए, फाइल में nextcloud_data के रूप में लिखा गया वॉल्यूम आमतौर पर डिस्क पर nextcloud_nextcloud_data के रूप में मौजूद होता है। docker volume ls वास्तविक नाम दिखाता है। inspect कमांड का आउटपुट कुछ इस तरह दिखता है (संक्षिप्त रूप में):

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

Mountpoint ही इसका उत्तर है। इसे कमांड से पढ़ें, न कि अनुमान लगाएं, क्योंकि यह बदल सकता है। Rootless Docker के तहत, पूरा Docker डेटा रूट उस यूजर की होम डायरेक्टरी के अंदर होता है जो डेमन चला रहा है, इसलिए वह पाथ कहीं और से शुरू होता है।

Bind mount इस सवाल को ही खत्म कर देता है। compose फाइल में - /srv/nextcloud/data:/data लिखें और होस्ट पाथ वही होगा जो आपने टाइप किया है, जिसे docker inspect, Source के रूप में रिपोर्ट करता है। यह विकल्प केवल पाथ से कहीं अधिक बदल देता है, क्योंकि named volumes and bind mounts ओनरशिप और बैकअप के मामले में अलग तरह से व्यवहार करते हैं।

डेटा डायरेक्टरी बैकअप क्यों नहीं है

Nextcloud मैनुअल में उन पांच चीजों की सूची दी गई है जिन्हें बैकअप में शामिल करना आवश्यक है: config फोल्डर, custom apps फोल्डर, data फोल्डर, theme फोल्डर और डेटाबेस। इस इमेज के साथ, config, apps और theme फोल्डर सभी /config के अंतर्गत रहते हैं, जबकि डेटाबेस अपने स्वयं के वॉल्यूम के साथ अपने अलग कंटेनर में चलता है। यदि आप केवल /data को कॉपी करते हैं, तो आपने समस्या का सबसे कम महत्वपूर्ण हिस्सा ही सुरक्षित किया है।

डेटाबेस इसलिए महत्वपूर्ण है क्योंकि वेब इंटरफेस कभी भी डायरेक्टरी की सूची नहीं दिखाता है। यह फाइल कैश से पंक्तियों (rows) को दिखाता है, यही कारण है कि मैनुअल आपको डेटा डायरेक्टरी में मैन्युअल रूप से फाइलें कॉपी करने के बाद स्कैन चलाने के लिए कहता है। यदि आप एक खाली डेटाबेस के साथ /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 के माध्यम से चलाएं। Nextcloud मैनुअल से लंबे sudo और php occ फॉर्म को कॉपी न करें, क्योंकि वह कंटेनर के बाहर किए गए इंस्टॉलेशन के लिए लिखा गया है।

डेटा वॉल्यूम को चुपचाप क्या भर रहा है?

प्रीव्यू और प्रति-उपयोगकर्ता हिस्ट्री उसी वॉल्यूम में रहते हैं जहाँ फाइलें होती हैं, और इनमें से कोई भी उस स्टोरेज आंकड़े में नहीं दिखता जो उपयोगकर्ता को वेब इंटरफेस में दिखाई देता है।

• प्रीव्यू उत्पन्न किए गए थंबनेल होते हैं। वे डेटा डायरेक्टरी के अंदर ऐप डेटा फोल्डर में रहते हैं, जिनका नाम appdata_ और उसके बाद इंस्टेंस आईडी होता है।
• हटाई गई फाइलें ट्रैश में रहती हैं। trashbin_retention_obligation डिफ़ॉल्ट रूप से auto पर सेट होता है, जो उन्हें 30 दिनों तक रखता है और उसके बाद केवल तभी हटाता है जब जगह की आवश्यकता होती है। हटाई गई फाइलें अभी भी उपयोगकर्ता के कोटा में गिनी जाती हैं, और जब कोटा पार हो जाता है, तो रिटेंशन सेटिंग को अनदेखा कर दिया जाता है और ट्रैश को तब तक साफ किया जाता है जब तक कि कोटा फिर से फिट न हो जाए।
• पुराने वर्ज़न भी बने रहते हैं। versions_retention_obligation भी डिफ़ॉल्ट रूप से auto पर सेट होता है। वर्ज़न्स ऐप कभी भी उपयोगकर्ता के पास उपलब्ध खाली जगह के 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 प्रोसेस होने वाली प्रत्येक फाइल को प्रिंट करता है, जिससे यह पता चलता है कि कमांड काम कर रही है या नहीं, बजाय इसके कि वह अटकी हुई लगे।

ओनरशिप (ownership) यह तय करती है कि स्कैन पर्याप्त है या नहीं। यदि कोई फाइल जिसे कंटेनर यूजर लिख नहीं सकता, उसे इंडेक्स कर लिया जाए, तो वह फाइल मूव होने से मना कर देगी। इस स्थिति में लिस्टिंग तो सही दिखेगी, लेकिन वेब इंटरफेस से फाइल को रीनेम या डिलीट करने का प्रयास विफल हो जाएगा।

PUID और PGID सेट करने के बाद writes विफल क्यों होते हैं?

क्योंकि kernel नामों की नहीं, बल्कि संख्याओं की तुलना करता है। PUID और PGID उस numeric user id (uid) और group id (gid) को सेट करते हैं जिसके तहत container process चलती है। host पर मौजूद हर file का भी एक numeric owner होता है। जब ये दोनों संख्याएँ अलग होती हैं, तो write करने की अनुमति नहीं दी जाती, चाहे दोनों तरफ नाम कुछ भी दिख रहे हों।

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

id abc उस uid और gid को print करता है जिसका container वास्तव में उपयोग कर रहा है, जो आपके द्वारा सेट किए गए PUID और PGID ही होते हैं। ls -ln numeric owners को print करता है, और -n महत्वपूर्ण है: साधारण ls -l उन संख्याओं को host की अपनी user list के माध्यम से translate करता है और एक ऐसा नाम दिखाता है जिसका container के अंदर कोई अर्थ नहीं होता। दोनों संख्याओं की तुलना करें।

फिर अनुमान लगाने के बजाय write का परीक्षण करें।

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

एक Permission denied जो /data को नाम देता है, वह पुष्टि है। container के अंदर से ownership को ठीक करें, फिर वही परीक्षण दोबारा चलाएँ।

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

इसे अंदर से करने का एक कारण है। rootless Docker के तहत container के user ids को /etc/subuid में subordinate range के माध्यम से map किया जाता है, इसलिए container के अंदर का uid 1000 host पर एक बहुत बड़े uid से संबंधित होता है। host-side का chown 1000:1000 तब एक ऐसा owner सेट करता है जिसका उपयोग container नहीं कर सकता, और write फिर भी विफल रहता है। container के अंदर chown चलाने से वही mapping लागू होती है जिसका उपयोग स्वयं Nextcloud process करती है, इसलिए संख्याएँ स्वतः ही मेल खा जाती हैं। यही कारण है कि किसी भी अन्य चीज़ को debug करने से पहले PUID और PGID का डिस्क पर मौजूद owner से मेल खाना आवश्यक है।

मैं बैकअप कैसे लूँ ताकि रिस्टोर वास्तव में काम करे?

डेटाबेस और फोल्डर को एक ही समय पर बैकअप लें। मेंटेनेंस मोड लॉगिन को रोक देता है, इसलिए डंप और कॉपी के बीच कोई भी अपलोड नहीं हो पाता है।

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 फाइल से शेल में पढ़ें। पुराने डेटाबेस इमेज mariadb-dump के बजाय mysqldump का उपयोग करते हैं, और मैनुअल में दोनों का उल्लेख है।

रिस्टोर करने के लिए, डंप को एक खाली डेटाबेस में लोड करें, दोनों आर्काइव को नए वॉल्यूम में अनपैक करें, कंटेनर शुरू करें, और फिर मेंटेनेंस मोड बंद करें। यदि फोल्डर और डंप अलग-अलग समय के हैं, तो फाइल कैश और डिस्क में विसंगति होगी, और occ files:scan --all केवल एक दिशा में मरम्मत कर पाएगा। यह उन फाइलों को ढूंढता है जो बिना किसी रो (row) के मौजूद हैं। यह उस फाइल को वापस नहीं ला सकता जिसकी ओर कोई रो इशारा कर रही है।

परिणाम को सर्वर से बाहर रखें। एक कॉपी जो उसी VPS के अंदर रहती है, वह VPS के साथ ही नष्ट हो जाती है, इसीलिए off-server रिपॉजिटरी में restic का उपयोग इस प्रक्रिया का हिस्सा होना चाहिए, और इसीलिए प्रोवाइडर स्नैपशॉट बैकअप से एक अलग टूल है। यदि आप अभी भी स्टैक बना रहे हैं, तो VPS पर पूर्ण Nextcloud इंस्टॉलेशन उस रिवर्स प्रॉक्सी और TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) सर्टिफिकेट को कवर करता है जिसे यह गाइड छोड़ देती है।

FAQ

Docker container में Nextcloud data directory कहाँ होती है?

linuxserver.io image के साथ यह container के अंदर /data पर होती है, और config.php के साथ installation /config के अंतर्गत होती है। ये container paths हैं। Host path के लिए, docker inspect nextcloud चलाएँ और Mounts section में Source value को पढ़ें, या volume पर docker volume inspect चलाएँ और Mountpoint पढ़ें। अन्य Nextcloud images अलग container paths का उपयोग करती हैं, इसलिए अपने द्वारा उपयोग किए गए tag के लिए documentation देखें, और docker exec -it nextcloud occ config:system:get datadirectory के साथ पुष्टि करें।

जो फाइलें मैं volume में copy करता हूँ, वे Nextcloud में क्यों नहीं दिखतीं?

Nextcloud directory को पढ़ने के बजाय अपने database में file cache से rows को list करता है, इसलिए जो फाइल Nextcloud के माध्यम से नहीं आती, उसकी कोई row नहीं होती और वह अदृश्य रहती है। एक folder के लिए docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" चलाएँ, या हर user के लिए occ files:scan --all चलाएँ। यदि फाइलें दिखती हैं लेकिन move या delete नहीं होतीं, तो इसका कारण ownership है: container user को उन्हें write करने में सक्षम होना चाहिए।

क्या Nextcloud restore करने के लिए data volume की एक copy पर्याप्त है?

नहीं। Data volume में file content होता है। Database में file index के साथ-साथ users और shares होते हैं, और config.php में database credentials और instance id होते हैं। एक सफल restore के लिए data folder, config folder, database, और यदि आप उपयोग करते हैं तो custom apps और theme folders की आवश्यकता होती है। इन सभी को एक ही समय पर लें, क्योंकि फाइलों से नया database उन फाइलों की ओर इशारा करता है जो मौजूद नहीं हैं।

मेरा data volume मेरे users द्वारा देखी जाने वाली फाइलों से बहुत बड़ा क्यों है?

Previews, deleted files और old versions उसी volume में रहते हैं और उनमें से कोई भी उस आंकड़े में नहीं दिखता जो user देखता है। docker exec -it nextcloud sh -c 'du -sh /data/*' के साथ मापें। Trash डिफ़ॉल्ट रूप से deleted files को 30 दिनों तक रखता है और केवल तभी जल्दी हटाता है जब space की आवश्यकता होती है, और Versions app user के पास मौजूद free space का आधा हिस्सा तक उपयोग कर सकता है। उन्हें occ trashbin:cleanup --all-users, occ versions:cleanup alice और occ preview:cleanup के साथ साफ़ करें, और उम्मीद रखें कि जैसे-जैसे लोग अपनी फाइलें खोलेंगे, previews फिर से बढ़ जाएंगे।

क्या मैं Nextcloud data directory को दूसरी disk पर ले जा सकता हूँ?

Nextcloud द्वारा ज्ञात path को बदलने के बजाय नए location को उसी container path पर mount करें। Container को stop करें, ownership को सुरक्षित रखते हुए (cp -a या rsync -aAX) पुरानी सामग्री को नई disk पर copy करें, अपने compose file में volume या bind mount को नए location पर point करें, फिर इसे दोबारा start करें। Nextcloud अभी भी /data देखता है, इसलिए database में किसी row को बदलने की आवश्यकता नहीं है। docker exec -it nextcloud occ config:system:get datadirectory और एक test upload के साथ पुष्टि करें।