VPS वर Docker वापरून Nextcloud कसे सेट करावे?

तुम्ही नेमके काय तयार करत आहात

हे मार्गदर्शक Docker Compose वापरून VPS वर Nextcloud चालवते, त्यासमोर Let's Encrypt TLS ठेवते आणि एक असा बॅकअप सेट करते जो खरोखर रिस्टोअर होतो. चार कंटेनर आणि एक प्रॉक्सी: अधिकृत nextcloud इमेज जी लूपबॅकवर ऐकते, Postgres जी फाईल मेटाडेटाच्या प्रत्येक तुकड्याला साठवते, Redis जी फाईल लॉक साठवते, Nextcloud इमेजची दुसरी प्रत जी फक्त cron लूप चालवते आणि होस्टवर nginx जी या सर्वांच्या समोर TLS टर्मिनेट करते. इन्स्टॉलेशनला वीस मिनिटे लागतात आणि तो महत्त्वाचा भाग नाही. पहिल्या तासात घेतलेले दोन निर्णय ठरवतात की एका वर्षानंतर तुमच्याकडे फाईल्स असतील की नाही: SQLite ऐवजी एक खरा डेटाबेस आणि असा बॅकअप जो डेटा डिरेक्टरी, डेटाबेस आणि config.php यांना एक सुसंगत संच म्हणून कॅप्चर करतो.

हे Ubuntu 24.04 LTS किंवा Debian 13, Docker च्या स्वतःच्या रिपॉझिटरीमधून इन्स्टॉल केलेले Compose v2 प्लगइन असलेले Docker Engine आणि VPS कडे cloud.example.com पॉइंट करणारे DNS A रेकॉर्ड (आणि जर तुमच्याकडे IPv6 असेल तर AAAA) आधीच तयार आहेत असे गृहीत धरते. या सर्वांसाठी तुमच्या नियंत्रणाखालील सर्व्हरची आवश्यकता आहे, कारण दुसऱ्याच्या SaaS वर TLS टर्मिनेशन आणि डेटाबेस डंप करणे शक्य नाही.

Sizing: मेमरीचा वापर नेमका कशामुळे होतो

Nextcloud च्या मेमरी वापरामध्ये प्रामुख्याने तीन गोष्टींचा वाटा असतो आणि त्यापैकी कोणतीही गोष्ट थेट "Nextcloud" नाही.

PHP workers. -apache इमेज प्रत्येक समवर्ती (concurrent) विनंती एका वर्कर प्रोसेसद्वारे पूर्ण करते, ज्यामध्ये PHP इंटरप्रिटर असतो. PHP ने विनंती रद्द करण्यापूर्वी प्रत्येक वर्कर PHP_MEMORY_LIMIT पर्यंत मेमरी वापरू शकतो. तुमची जास्तीत जास्त मेमरी वापरण्याची शक्यता साधारणपणे समवर्ती विनंत्या × मेमरी मर्यादा इतकी असते आणि डेस्कटॉप सिंक क्लायंट प्रत्येक वापरकर्त्यासाठी अनेक समांतर कनेक्शन्स उघडतो. वापरकर्त्यांची संख्या नाही, तर समवर्ती विनंत्यांची संख्या मेमरीची मर्यादा ठरवते.

डेटाबेस. Postgres प्रत्येक कनेक्शनसाठी एक बॅकएंड तयार करतो आणि शेअर्ड बफर मेमरीमध्ये ठेवतो. याचा वर्किंग सेट फाईल्सच्या संख्येनुसार वाढतो, फाईल्सच्या आकारानुसार नाही: oc_filecache मध्ये प्रत्येक वापरकर्त्याच्या प्रत्येक फाईलसाठी एक रो (row) असते. शंभर मोठ्या फाईल्सपेक्षा एक लाख लहान फाईल्सचा डेटाबेस अधिक मेमरी घेतो.

Preview generation. थंबनेल तयार करताना मूळ इमेज पूर्ण रिझोल्यूशनमध्ये मेमरीमध्ये डिकोड केली जाते. व्हिडिओ प्रिव्ह्यूसाठी ffmpeg चा वापर केला जातो. occ preview:generate-all चालवल्यास हे काम वारंवार आणि सलग केले जाते, ज्यामुळे लहान VPS वर OOM killer सक्रिय होण्याची शक्यता सर्वात जास्त असते.

Redis चा वापर तुलनेने कमी असतो. तुम्ही नंतर जोडलेली कोणतीही गोष्ट, जसे की Collabora, full-text search, किंवा अँटीव्हायरस स्कॅनर, ही एक स्वतंत्र सेवा असते आणि तिचा स्वतःचा मेमरी वापर असतो. त्यामुळे कोणतीही सेवा सुरू करण्यापूर्वी ती तुमच्या प्लॅनिंगमध्ये समाविष्ट करा.

जर तुमच्याकडे RAM कमी असेल, तर हे उपाय करा: PHP_MEMORY_LIMIT कमी करा, preview_max_x / preview_max_y / preview_max_filesize_image वर मर्यादा घाला, enabledPreviewProviders मध्ये फक्त तुम्हाला आवश्यक असलेले फॉरमॅट्स ठेवा आणि trashbin_retention_obligation व versions_retention_obligation सेट करा जेणेकरून डेटा डिरेक्टरी फाईल्सच्या आकारापेक्षा कित्येक पटीने वाढणार नाही. एक swap file जोडा. Swap हळू काम करते, पण अपग्रेड दरम्यान OOM kill होणे त्यापेक्षा जास्त त्रासदायक असते.

SQLite का निकामी होते

Nextcloud मध्ये SQLite चे समर्थन दिलेले असते आणि अधिकृत इमेज आनंदाने त्याचा वापर करते. पण तुम्ही तसे करू नका. SQLite डेटाबेस-व्यापी लॉक वापरून लेखनाचे (writes) क्रमवारीकरण करते: संपूर्ण फाईलसाठी एका वेळी फक्त एकच रायटर काम करू शकतो. Nextcloud मध्ये सतत लेखन सुरू असते; फाईल लॉक्स, ॲक्टिव्हिटी रोज, कॅशे एन्ट्रीज आणि जॉब स्टेट यांसारख्या गोष्टींमुळे आणि एखादा डेस्कटॉप क्लायंट डिरेक्टरी ट्री सिंक करत असताना अनेक समांतर विनंत्या (parallel requests) निर्माण होतात. या पॅटर्नमुळे तुम्हाला SQLSTATE[HY000]: General error: 5 database is locked आणि HTTP 500 एरर्स मिळतात आणि जेव्हा तुमची इन्स्टन्स खऱ्या अर्थाने उपयुक्त ठरू लागते, तेव्हाच हे अपयश समोर येते.

नंतरच्या टप्प्यावर occ db:convert-type वापरून रूपांतर करणे शक्य आहे, परंतु थेट डेटासेटवर ही एक प्रदीर्घ आणि 'सर्व किंवा काहीही नाही' (all-or-nothing) स्वरूपाची स्थलांतर प्रक्रिया आहे. त्यामुळे सुरुवातीपासूनच Postgres किंवा MariaDB वापरा.

Compose फाईल

हे /srv/nextcloud/compose.yaml मध्ये ठेवा आणि secrets ला 600 मोड असलेल्या .env फाईलमध्ये ठेवा.

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}

  app:
    image: nextcloud:35-apache
    restart: unless-stopped
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      REDIS_HOST: redis
      REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.example.com
      TRUSTED_PROXIES: 172.16.0.0/12
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.example.com
      APACHE_DISABLE_REWRITE_IP: "1"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_LIMIT: 10G

  cron:
    image: nextcloud:35-apache
    restart: unless-stopped
    entrypoint: /cron.sh
    depends_on: [db, redis]
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data

volumes:
  db:
  html:

मेजर टॅग पिन करा आणि 35 जसेच्या तसे कॉपी करण्यापूर्वी Docker Hub वर सध्याचा टॅग तपासा. 21 ऑक्टोबर 2026 पर्यंत, Nextcloud 33, 34 आणि 35 या आवृत्त्यांचे समर्थन करते. 31 ही आवृत्ती फेब्रुवारी 2026 मध्ये आणि 32 ही आवृत्ती सप्टेंबर 2026 मध्ये कालबाह्य (end of life) झाली आहे, त्यामुळे जुन्या मार्गदर्शिकेतून कॉपी केलेला टॅग अशी आवृत्ती इन्स्टॉल करेल ज्याला आता कोणतेही अपडेट्स मिळत नाहीत. latest तुम्हाला भविष्यातील एखाद्या docker compose pull वर मेजर बाउंड्री ओलांडून घेऊन जाईल आणि Nextcloud अशा प्रकारच्या अपग्रेडला सपोर्ट करत नाही.

डेटा डिरेक्टरी ही named volume नसून bind mount आहे, हे हेतुपुरस्सर केले आहे: ज्या पाथवर तुम्ही थेट बॅकअप टूल पॉइंट करू शकता, तो पाथ नीटनेटकेपणापेक्षा जास्त महत्त्वाचा असतो. ती इमेजच्या www-data UID सह आणि Nextcloud ला आवश्यक असलेल्या परवानग्यांसह तयार करा:

sudo mkdir -p /srv/nextcloud/data
sudo chown -R 33:33 /srv/nextcloud/data
sudo chmod 0770 /srv/nextcloud/data

पोर्ट पब्लिश करण्याकडे लक्ष द्या: 127.0.0.1:8080:80. Docker पोर्ट्स पब्लिश करण्यासाठी DNAT नियम लिहिते, जे ufw च्या INPUT चेनमध्ये पॅकेट येण्यापूर्वीच तपासले जातात. त्यामुळे, केवळ 8080:80 वापरल्यास ufw च्या नियमांकडे दुर्लक्ष होऊन Nextcloud सार्वजनिक इंटरनेटवर उघडे (unencrypted) राहू शकते. loopback वर बाइंड केल्यामुळे ते सार्वजनिक इंटरफेसपासून सुरक्षित राहते. त्यानंतर फायरवॉलने फक्त प्रॉक्सीला परवानगी देणे आवश्यक असते. जर तुम्हाला SSH संपूर्ण इंटरनेटसाठी उघडे ठेवायचे नसेल, तर self-hosted WireGuard VPN द्वारे VPS ला ॲक्सेस करणे तुम्हाला पोर्ट 22 सार्वजनिक नियमांमधून पूर्णपणे काढून टाकण्याची सुविधा देते:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

docker compose up -d वापरून सेवा सुरू करा आणि त्यानंतर docker compose logs -f app द्वारे लॉग्स तपासा. पहिल्यांदा बूट होताना संपूर्ण ॲप्लिकेशन ट्री व्हॉल्यूममध्ये कॉपी केली जाते आणि इंस्टॉलर रन होतो; जोपर्यंत ही प्रक्रिया पूर्ण होत नाही, तोपर्यंत कंटेनर कोणत्याही विनंतीला प्रतिसाद देत नाही.

TLS आणि रिव्हर्स प्रॉक्सी

तुमच्या डिस्ट्रोमधून nginx आणि certbot इन्स्टॉल करा, योग्य server_name सह एक साधा port-80 सर्व्हर ब्लॉक तयार करा आणि त्यानंतर certbot ला तो पुन्हा लिहिण्याची परवानगी द्या. HTTP-01 चॅलेंजची कार्यपद्धती, रिन्यूअल टाइमर आणि अपयशाची कारणे Ubuntu 24.04 वर certbot आणि nginx वापरून Let's Encrypt प्रमाणपत्रे जारी करणे यामध्ये सविस्तर दिली आहेत:

sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d cloud.example.com

Certbot यामध्ये ssl_certificate ओळी आणि :80 → :443 रिडायरेक्ट जोडते, तसेच 90-दिवसांचे प्रमाणपत्र रिन्यू करण्यासाठी एक systemd टाइमर इन्स्टॉल करते. systemctl list-timers | grep certbot वापरून तो अस्तित्वात असल्याची खात्री करा; जर रिन्यूअल टाइमर इनेबल केला नसेल, तर ते 90 दिवसांचे एक 'फ्यूज' ठरू शकते.

प्रॉक्सी ब्लॉक खालीलप्रमाणे आहे:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name cloud.example.com;

    # certbot manages ssl_certificate / ssl_certificate_key here

    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

    client_max_body_size 10G;
    client_body_timeout 300s;

    location = /.well-known/carddav { return 301 /remote.php/dav; }
    location = /.well-known/caldav  { return 301 /remote.php/dav; }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_request_buffering off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

nginx 1.25.1 आणि त्यापुढील आवृत्त्यांवर, http2 on; जोडा. हे डिरेक्टिव्ह 1.25.0 मध्ये उपलब्ध नाही आणि ते असल्यास nginx सुरू होणार नाही. Ubuntu 24.04 मध्ये जुनी बिल्ड आहे, जिथे याला पर्याय म्हणून listen 443 ssl http2; वापरले जाते. तुमची बिल्ड कोणता पर्याय स्वीकारते हे nginx -t तुम्हाला सांगेल.

जर client_max_body_size खूप कमी असेल, तर nginx मोठ्या फाईल अपलोडला थेट 413 एरर देऊन नाकारते. जर रीड टाइमआउट खूप कमी असतील, तर अपलोड अर्धवट थांबतो. वरील व्हॅल्यूज या दोन्ही समस्या टाळतात. proxy_request_buffering off मुळे फाईल प्रॉक्सीच्या डिस्कवर पूर्णपणे सेव्ह न होता थेट स्ट्रीम केली जाते.

एका ॲपसाठी होस्टवर चालणारे nginx हे सर्वात सोपे आणि प्रभावी माध्यम आहे. जर Nextcloud ला इतर कंटेनर्ससोबत VPS शेअर करायचा असेल, तर अनेक ॲप्ससाठी Docker Compose रिव्हर्स प्रॉक्सी म्हणून Traefik चालवणे हा पर्याय राउटिंग आणि प्रमाणपत्र जारी करण्याची प्रक्रिया कंटेनर लेबल्समध्ये हलवतो. तिथेही समान client_max_body_size आणि टाइमआउटच्या समस्या मिडिलवेअर आणि ट्रान्सपोर्ट सेटिंग्जच्या स्वरूपात पुन्हा उद्भवतात.

trusted_proxies आणि overwriteprotocol

बहुतेक self-hosted Nextcloud इन्स्टन्समध्ये येथेच चूक होते आणि त्याची लक्षणे मूळ कारणाशी संबंधित वाटत नाहीत.

X-Forwarded-Proto: https चा विचार तेव्हाच केला जातो जेव्हा विनंती trusted_proxies मध्ये सूचीबद्ध असलेल्या पत्त्यावरून येते. जेव्हा याचा विचार केला जात नाही, तेव्हा Nextcloud ला वाटते की विनंती साधी HTTP आहे आणि ते http:// URL तयार करते; प्रॉक्सी त्या URL ला HTTPS वर रिडायरेक्ट करते; ब्राउझर त्याचे अनुसरण करतो; Nextcloud पुन्हा http:// तयार करते. हेच रिडायरेक्ट लूपचे कारण आहे. OVERWRITEPROTOCOL: https स्कीमची पर्वा न करता ती निश्चित करते.

TRUSTED_PROXIES मधील सापळा असा आहे की Nextcloud ला दिसणारा पत्ता 127.0.0.1 नसतो. nginx होस्टवर चालतो आणि पब्लिश केलेल्या पोर्टशी कनेक्ट होतो, त्यामुळे कंटेनरला Docker ब्रिज गेटवे दिसतो, जो 172.x मधील काहीतरी असतो. खरा सबनेट शोधा:

docker network inspect nextcloud_default \
  -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

तो CIDR (किंवा कव्हरिंग 172.16.0.0/12) TRUSTED_PROXIES मध्ये टाका. जर तो खूप मोठा सेट केला, तर कोणताही क्लायंट X-Forwarded-For ला स्पूफ करू शकतो; जर तो चुकीचा सेट केला, तर प्रत्येक लॉगिन गेटवे पत्त्यावरून आल्यासारखे दिसते, ब्रूट-फोर्स प्रोटेक्शन संपूर्ण इन्स्टन्सला एकाच वेळी ब्लॉक करते आणि ॲडमिन ओव्हरव्ह्यूमध्ये "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy." असा संदेश दिसतो.

OVERWRITECLIURL हे cron कंटेनरसाठी महत्त्वाचे आहे, ज्याच्याकडे होस्टनेमचा अंदाज लावण्यासाठी कोणतीही येणारी विनंती नसते. त्याशिवाय, बॅकग्राउंड जॉब्स localhost साठी लिंक्स तयार करतात आणि ईमेल नोटिफिकेशन्समध्ये न वापरता येण्याजोग्या URL पाठवल्या जातात.

बॅकग्राउंड जॉब्स: cron, AJAX नाही

Nextcloud चा डीफॉल्ट जॉब रनर AJAX आहे: जेव्हा कोणीतरी पेज लोड करते, तेव्हाच जॉब्स कार्यान्वित होतात. पहाटे 04:00 वाजता कोणीही ब्राउझ करत नसल्यामुळे, कचरा (trash) काढून टाकणे, व्हर्जन क्लीनअप, प्रिव्ह्यू आणि फेडरेटेड रिट्राय थांबतात. याचे पहिले लक्षण म्हणजे डेटा डिरेक्टरीचा आकार सतत वाढत राहणे. वरील cron सर्व्हिस त्याच व्हॉल्यूम्सवर अधिकृत /cron.sh लूप चालवते. Nextcloud ला याची सूचना द्या:

docker compose exec -u www-data app php occ background:cron

प्रत्येक occ कमांड या स्वरूपाचे पालन करते: docker compose exec -u www-data app php occ <command>. यासाठी alias तयार करणे फायदेशीर ठरते.

बॅकअप: तीन गोष्टी, किंवा काहीच नाही

केवळ फाइलसिस्टमचा बॅकअप घेतल्यास तो बिघडलेल्या इन्स्टन्सवर रिस्टोअर होऊ शकत नाही. डेटा डिरेक्टरीमध्ये बाइट्स असतात; Postgres मध्ये फाइल कॅशे, शेअर्स, युजर्स आणि ॲपची स्थिती असते; config.php मध्ये डेटाबेस क्रेडेंशियल्स, इन्स्टन्स ID आणि पासवर्ड सॉल्ट असतात. डेटाबेसशिवाय फाइल्स रिस्टोअर केल्यास Nextcloud त्यांना पाहू शकत नाही. config.php शिवाय डेटाबेस रिस्टोअर केल्यास तो डेटाबेस उघडू शकत नाही. जुना डेटाबेस नवीन डेटा डिरेक्टरीवर रिस्टोअर केल्यास शेअर्स अशा फाइल्सना पॉइंट करतील ज्यांची जागा बदलली आहे.

क्विझ्ड (quiesced) इन्स्टन्सवरून या तिन्ही गोष्टींचा बॅकअप घ्या:

#!/usr/bin/env bash
set -euo pipefail
cd /srv/nextcloud
DEST="/var/backups/nextcloud/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$DEST"

occ() { docker compose exec -T -u www-data app php occ "$@"; }

occ maintenance:mode --on
trap 'occ maintenance:mode --off' EXIT

docker compose exec -T db \
  pg_dump -U nextcloud --clean --if-exists nextcloud | gzip > "$DEST/db.sql.gz"

docker compose exec -T app \
  tar -C /var/www/html -cf - config custom_apps themes > "$DEST/app.tar"

rsync -a --delete /srv/nextcloud/data/ /var/backups/nextcloud/data/

मेंटेनन्स मोडमुळे डंप आणि फाइल कॉपी एकमेकांशी सुसंगत राहतात. हा मोड वगळल्यास, तुम्ही असा डेटाबेस कॅप्चर कराल जो अशा फाइलचा संदर्भ देतो जिथे rsync अजून पोहोचलेच नव्हते. लक्षात ठेवा की स्क्रिप्ट टाइमस्टॅम्प केलेले डेटाबेस डंप ठेवते, परंतु डेटा डिरेक्टरीचे फक्त एक रोलिंग मिरर ठेवते. rsync --delete प्रत्येक रनला ते ओव्हरराईट करते, त्यामुळे फक्त सर्वात नवीन डंप फाइल कॉपीशी जुळतो.

त्यानंतर, बॅकअप सर्व्हरवरून बाहेर काढा. ज्या VPS वर बॅकअप घेतला आहे, त्याच VPS वर तो ठेवणे म्हणजे बॅकअप नसून केवळ एक प्रत आहे. restic चा वापर करून ऑब्जेक्ट स्टोरेज किंवा दुसऱ्या होस्टवर बॅकअप घेणे हा सामान्य उपाय आहे. त्याचे डीड्युप्लिकेशन (deduplication) डेटा डिरेक्टरीसाठी रात्रीच्या tarball पेक्षा अधिक प्रभावी ठरते. रिपॉझिटरी इनिशियलायझेशनपासून ते रात्रीच्या टाइमरपर्यंत आणि रिस्टोअर सरावापर्यंतची संपूर्ण माहिती off-box VPS backups with restic मध्ये दिली आहे.

रिस्टोअर करणे म्हणजे केवळ उलट प्रक्रिया करणे नव्हे. नव्याने सुरू झालेला स्टॅक इंस्टॉलर चालवतो आणि एक नवीन config.php, नवीन इन्स्टन्स ID आणि पासवर्ड सॉल्ट लिहितो. अशा नवीन ओळखीवर डंप इम्पोर्ट केल्यास सेशन्स आणि शेअर टोकन्स निकामी होतात. त्याऐवजी जुनी ओळख आधी परत आणा, या क्रमाने:

docker compose up -d && docker compose stop app cron    # create the volumes, then halt the app
sudo rsync -a --delete /var/backups/nextcloud/data/ /srv/nextcloud/data/
docker compose run --rm -T --entrypoint "" app \
  tar -C /var/www/html -xf - < app.tar                  # the original config.php returns
gunzip -c db.sql.gz | docker compose exec -T db psql -U nextcloud -d nextcloud
docker compose start app cron
docker compose exec -T -u www-data app php occ maintenance:mode --off
docker compose exec -T -u www-data app php occ files:scan --all

files:scan फाइल कॅशेला डिस्कवर असलेल्या प्रत्यक्ष डेटाशी जुळवते. याची एकदा सराव म्हणून दुसऱ्या VPS वर चाचणी करा, जेणेकरून गरज पडल्यास अडचण येणार नाही. डिस्कवरील बाइट्स आणि Postgres मधील मेटाडेटा यांच्यातील हाच फरक इतर सर्व ॲप्सना लागू होतो, म्हणूनच an Immich backup that captures the library but not the database restores to an empty timeline असे घडते.

अपग्रेड्स: एका वेळी एकच मेजर व्हर्जन

Nextcloud एका वेळी फक्त एकच मेजर व्हर्जन अपग्रेड करण्यास सपोर्ट करते. अधिकृत Docker इमेज वापरताना, 29 वरून थेट 31 वर जाण्याचा प्रयत्न केल्यास अपग्रेडर सुरू होत नाही. कंटेनरचा entrypoint रन होण्यापूर्वी मेजर व्हर्जन्सची तुलना करतो, occ upgrade चालवण्यापूर्वी Can't start Nextcloud because upgrading from <installed version> to <image version> is not supported. आणि त्यानंतर It is only possible to upgrade one major version at a time. प्रिंट करतो आणि प्रक्रिया थांबवतो. कंटेनर सुरू होण्यास नकार देतो (restart: unless-stopped मुळे तो वारंवार रीस्टार्ट होतो आणि त्याच ओळी प्रिंट करतो), maintenance mode कधीही सुरू होत नाही, आणि डेटा तसेच डेटाबेसमध्ये कोणताही बदल होत नाही. टॅगला पुढील एका मेजर व्हर्जनवर सेट करा आणि पुन्हा प्रयत्न करा.

Docker अपग्रेड करण्याची पद्धत अशी आहे: बॅकअप घ्या, app आणि cron या दोन्ही सर्व्हिसेसमध्ये टॅग एक मेजर व्हर्जनने वाढवा (36 रिलीज झाल्यावर 35 वरून 36 वर जा, ज्याचे नियोजन Nextcloud ने फेब्रुवारी 2027 साठी केले आहे), त्यानंतर docker compose pull && docker compose up -d चालवा आणि शेवटी docker compose logs -f app करा. इमेजचा entrypoint अस्तित्वात असलेल्या डेटाच्या तुलनेत नवीन कोड ओळखतो आणि स्वतःहून occ upgrade चालवतो. ही प्रक्रिया मध्येच खंडित करू नका. जेव्हा लॉग्स शांत होतील, तेव्हा docker compose exec -u www-data app php occ status चालवा आणि versionstring तपासा, तसेच सर्व ॲप्स पुन्हा सुरू झाले आहेत याची खात्री करा.

स्वतःला सुरक्षित ठेवण्यासाठी दोन नियम पाळा: एका वेळी एकच मेजर व्हर्जन वाढवा, पडताळणी करा आणि मगच पुढचे व्हर्जन वाढवा. तसेच, cron मध्ये बदल न करता कधीही app सर्व्हिसमधील टॅग बदलू नका; एकाच डेटाबेसवर दोन भिन्न Nextcloud व्हर्जन्स चालवणे डेटा करप्शनला निमंत्रण देते.

तुम्हाला दिसणाऱ्या प्रत्यक्ष त्रुटी

"Your data directory is readable by other people. Please change the permissions to 0770 so that the directory cannot be listed by other people." डिरेक्टरीच्या मोडचा शेवटचा अंक, जो इतर वापरकर्त्यांसाठी असतो, तो शून्य नाही. इतरांसाठी कोणतीही रीड, राईट किंवा एक्झिक्युट बिट या त्रुटीला ट्रिगर करते. ग्रुप बिट्स कधीही तपासले जात नाहीत, कारण 0770 स्वतः ग्रुपला पूर्ण ॲक्सेस देते. Nextcloud प्रथम स्वतःहून chmod 0770 करण्याचा प्रयत्न करते आणि जर ते अयशस्वी झाले तरच चेतावणी देते, जे bind mount च्या बाबतीत सहसा याचा अर्थ असा होतो की डिरेक्टरीची मालकी UID 33 कडे नाही. sudo chown -R 33:33 /srv/nextcloud/data आणि sudo chmod 0770 /srv/nextcloud/data.

"Your data directory is invalid. Ensure there is a file called ".ncdata" in the root of the data directory." bind mount अशा ठिकाणी पॉइंट करत आहे जिथे Nextcloud ने कधीही इनिशियलायझेशन केले नाही, पाथमध्ये टायपो आहे किंवा कार्यरत इन्स्टन्सच्या खाली एक नवीन रिकामी डिरेक्टरी बदलली गेली आहे. होस्ट पाथ व्हॉल्यूम लाईनशी जुळतो का ते तपासा.

"Access through untrusted domain." विनंतीमधील होस्टनेम trusted_domains मध्ये नाही. NEXTCLOUD_TRUSTED_DOMAINS फक्त पहिल्या इन्स्टॉलच्या वेळी लागू होते; त्यानंतर ते थेट सेट करा: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, /var/log/nginx/error.log मध्ये connect() failed (111: Connection refused) while connecting to upstream सह. nginx ने 127.0.0.1:8080 वर कशाशीही संपर्क साधला नाही. एकतर कंटेनर अजून इनिशियलाईज होत आहे (docker compose logs app तपासा), तो बंद झाला आहे (docker compose ps), किंवा पब्लिश लाईन proxy_pass पोर्टशी जुळत नाही. ss -ltnp | grep 8080 सह याची खात्री करा.

एक रिडायरेक्ट लूप, किंवा ॲडमिन ओव्हरव्ह्यूमध्ये "insecure" चेतावणी. OVERWRITEPROTOCOL: https गहाळ आहे, किंवा TRUSTED_PROXIES मध्ये Docker गेटवे सबनेट नाही. वरील प्रॉक्सी विभाग पहा.

LockedException: "files/..." is locked. REDIS_HOST सेट केल्यावर, इमेज Redis ला लॉकिंग बॅकएंड म्हणून कॉन्फिगर करते आणि जुने लॉक दुर्मिळ असतात. त्याशिवाय, लॉक डेटाबेस टेबल oc_file_locks मध्ये राहतात आणि राईट दरम्यान बंद झालेली विनंती मागे ओळी (rows) सोडून जाते. हाताने लॉक ओळी साफ करण्यापूर्वी, Redis खरोखर वापरात असल्याची खात्री करा, occ config:system:get memcache.locking ने Redis क्लास परत केला पाहिजे.

"The PHP memory limit is below the recommended value of 512 MB." PHP_MEMORY_LIMIT वाढवा आणि कंटेनर पुन्हा तयार करा. यामुळे तुमच्या worst-case सीलिंगवर काय परिणाम होतो ते लक्षात ठेवा.

मोठ्या प्रमाणावर काम करताना काय बिघडते

पहिली अडचण म्हणजे डेटा डिरेक्टरीचा आकार व्हॉल्यूमच्या क्षमतेपेक्षा वाढणे. VPS वर व्हॉल्यूम वाढवणे म्हणजे रिसाईज करणे आणि त्यानंतर फाइलसिस्टम वाढवणे, ही प्रक्रिया डिस्क 100% भरल्यावर करण्यापेक्षा आधीच नियोजित करणे जास्त सोयीचे असते. त्यामुळे डिस्क वापराबाबत आताच अलर्ट सेट करा, नंतर नाही.

दुसरी अडचण म्हणजे oc_filecache. फाइल्सची यादी आणि सिंक स्कॅनची गती रो (row) संख्येनुसार कमी होते. यावर उपाय म्हणजे डेटाबेसचे व्यवस्थापन: Postgres ला वेगवान स्टोरेजवर ठेवा, त्याला पुरेशी shared memory वापरू द्या आणि कचरा किंवा जुन्या आवृत्त्या साठवून ठेवण्याऐवजी retention settings वापरून त्या वेळोवेळी काढून टाका.

तिसरी अडचण म्हणजे प्रिव्ह्यू जनरेशन इतर कामांशी स्पर्धा करते. लहान सर्व्हरवर प्रिव्ह्यू प्रोव्हायडर मर्यादित ठेवा आणि कामाच्या वेळेत कधीही occ preview:generate-all चालवू नका. जर तुमच्या स्टोरेजमध्ये फोन कॅमेरा रोलचा मोठा वाटा असेल, तर थंबनेल तयार करण्याचे काम एका स्वतंत्र फोटो सर्व्हरवर करणे योग्य ठरेल. RAM, फोन ॲप्स आणि बॅकअप कमांड्सच्या संदर्भात PhotoPrism आणि Immich ची तुलना या लेखात Nextcloud बॉक्सच्या तुलनेत त्यांचा खर्च काय आहे हे स्पष्ट केले आहे.

या पलीकडे, वास्तव हे आहे की अतिरिक्त सेवांना स्वतंत्र मशीनची गरज असते. Collabora आणि full-text search या स्वतंत्र सेवा आहेत ज्यांचे स्वतःचे मेमरी प्रोफाइल असते. त्यांना त्याच बॉक्सवर ठेवणे जिथे तुमच्या फाइल्सची एकमेव प्रत आहे, ते अपयशाची व्याप्ती वाढवते आणि त्याचा कोणताही फायदा होत नाही. जर तुम्हाला ब्राउझरमध्ये डॉक्युमेंट एडिटिंग हवे असेल, तर OnlyOffice आणि Collabora मधील RAM आणि कनेक्शन मर्यादा यावरून ठरवा की 2 ते 4 GB चा VPS कोणत्या सेवेला हाताळू शकेल. जेव्हा व्हॉल्यूमचा आकार अपुरा पडू लागतो, तेव्हा फाइल स्टोरेज S3-compatible प्रायमरी स्टोरेजवर हलवा. लक्षात ठेवा की यामुळे बॅकअप घेणे सोपे होण्याऐवजी कठीण होते: डेटाबेसमध्ये अजूनही मेटाडेटा असतो आणि तो बकेटच्या डेटासोबतच डंप करणे आवश्यक असते.

एकदा का तुमची इन्स्टन्स प्रत्यक्ष वापरकर्त्यांना सेवा देऊ लागली की, तिच्या समोर Uptime Kuma लावा, जेणेकरून सिंक क्लायंटना समजण्याआधी तुम्हाला डाउनटाइमची माहिती मिळेल. प्रायव्हेट क्लाउड तुमच्या स्वतःच्या मेल सर्व्हरसोबत उत्तम काम करते. जर तुम्हाला सेवा हाताने जोडायच्या नसतील, तर Cloudron, CasaOS आणि Coolify या प्लॅटफॉर्मची तुलना करा जे तुमच्यासाठी हे काम करतात. जर या यादीत पुढे एखादे self-hosted सर्च इंजिन असेल, तर वरील समस्यांपेक्षा वेगळ्या प्रकारच्या समस्यांची अपेक्षा ठेवा: SearXNG चे 429 एरर्स हे एकतर त्याच्या स्वतःच्या रेट लिमिटरमुळे येतात किंवा अपस्ट्रीम इंजिन्स तुमच्या VPS IP ला ब्लॉक करत असल्यामुळे येतात, आणि हे केवळ लॉग्स तपासूनच कळू शकते.

FAQ

मी Postgres ऐवजी SQLite वर Nextcloud चालवू शकतो का?

तुम्ही हे करू शकता आणि अधिकृत इमेज तुम्हाला तसे करण्याची परवानगी देते, परंतु डेस्कटॉप सिंक क्लायंटकडून येणाऱ्या समांतर विनंत्यांमुळे SQLSTATE[HY000]: General error: 5 database is locked आणि HTTP 500 एरर येऊ शकतात. SQLite संपूर्ण डेटाबेसवर राईट लॉक (write lock) लावते, तर Nextcloud सतत फाईल लॉक्स, ॲक्टिव्हिटी रोज आणि जॉब स्टेट्स लिहित असते. सुरुवातीपासूनच Postgres किंवा MariaDB वापरा; occ db:convert-type उपलब्ध आहे, परंतु थेट डेटावर ही एक मोठी आणि जोखमीची प्रक्रिया आहे.

Nextcloud VPS साठी प्रत्यक्षात किती RAM लागते?

वापरकर्त्यांच्या संख्येपेक्षा एकाच वेळी होणाऱ्या विनंत्यांच्या (concurrency) आधारावर आकारमान ठरवा. सर्वात वाईट परिस्थितीत लागणारी मेमरी म्हणजे एकाच वेळी येणाऱ्या विनंत्यांची संख्या गुणिले PHP_MEMORY_LIMIT, अधिक Postgres चे शेअर्ड बफर आणि प्रत्येक कनेक्शनसाठी एक बॅकएंड, तसेच प्रीव्ह्यू जनरेशनमुळे लागणारी अतिरिक्त मेमरी. जर तुम्ही प्रीव्ह्यू मर्यादित केले आणि स्वॅप (swap) वापरले, तर 2 GB चा सर्व्हर लहान कुटुंबासाठी पुरेसा आहे; मात्र Collabora किंवा फुल-टेक्स्ट सर्च जोडल्यास तुम्हाला अतिरिक्त सेवांसाठी अधिक मेमरी लागेल.

nginx reverse proxy मागे मोठ्या फाईल्स अपलोड करताना अपयश का येते?

प्रॉक्सीवरील दोन सेटिंग्ज सहसा याचे कारण असतात. जर client_max_body_size डीफॉल्ट 1 MB वर असेल, तर nginx त्यापेक्षा मोठ्या विनंत्या थेट 413 (Request Entity Too Large) एरर देऊन नाकारते, जो एरर nginx च्या एरर लॉगमध्ये दिसतो. proxy_read_timeout / proxy_send_timeout ची कमी व्हॅल्यू मोठ्या ट्रान्सफरमध्ये अडथळा आणते. दोन्ही व्हॅल्यू पुरेशा वाढवा, proxy_request_buffering off ला 'spool' ऐवजी 'stream' वर सेट करा आणि ॲप कंटेनरवरील PHP_UPLOAD_LIMIT देखील त्यानुसार वाढवा.

Nextcloud मध्ये रीडायरेक्ट लूप का येतो किंवा रिव्हर्स प्रॉक्सीबद्दल चेतावणी का मिळते?

कंटेनरला 127.0.0.1 वरील nginx दिसत नाही, त्याला फक्त 172.x मधील Docker ब्रिज गेटवे दिसतो. जेव्हा तो पत्ता TRUSTED_PROXIES मध्ये नसतो, तेव्हा X-Forwarded-Proto: https हेडरकडे दुर्लक्ष केले जाते, Nextcloud http:// URL तयार करते आणि प्रॉक्सी त्यांना पुन्हा परत पाठवते. TRUSTED_PROXIES ला प्रत्यक्ष ब्रिज सबनेटवर सेट करा आणि OVERWRITEPROTOCOL: https ला पिन करा.

मी Nextcloud 29 वरून थेट 31 वर अपग्रेड करू शकतो का?

नाही. Nextcloud प्रत्येक अपग्रेडमध्ये फक्त एक मेजर व्हर्जन वाढवण्यास समर्थन देते. अधिकृत Docker इमेजमध्ये, एंट्रीपॉईंट occ upgrade चालवण्यापूर्वी मेजर व्हर्जन तपासते, It is only possible to upgrade one major version at a time. प्रिंट करते आणि थांबते. त्यामुळे कंटेनर सुरू होत नाही आणि तुमचा डेटा व डेटाबेस सुरक्षित राहतात. त्याऐवजी टॅग 30 वर सेट करा: बॅकअप घ्या, app आणि cron या दोन्ही सेवांचे टॅग एक मेजर व्हर्जनने वाढवा, docker compose pull && docker compose up -d करा, occ status सह पडताळा आणि त्यानंतर पुन्हा ही प्रक्रिया करा.