VPS वर Docker वापरून Nextcloud कसे इंस्टॉल करावे?

What you are actually building

This guide runs Nextcloud on a VPS with Docker Compose, puts Let's Encrypt TLS in front of it, and sets up a backup that actually restores. Four containers and a proxy: the official nextcloud image listening on loopback, Postgres holding every piece of file metadata, Redis holding the file locks, a second copy of the Nextcloud image running nothing but the cron loop, and nginx on the host terminating TLS in front of all of it. The install itself takes twenty minutes, and it is not the part that matters. Two decisions made in the first hour decide whether you still have your files in a year: a real database instead of SQLite, and a backup that captures the data directory, the database and config.php as one consistent set.

This assumes Ubuntu 24.04 LTS or Debian 13, Docker Engine with the Compose v2 plugin installed from Docker's own repository, and a DNS A record (plus AAAA if you have IPv6) already pointing cloud.example.com at the VPS. All of it needs a server you control, there is no way to do TLS termination and a database dump on someone else's SaaS.

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

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

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

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

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

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

जर तुमच्याकडे 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 मध्ये ठेवा, आणि सीक्रेट्स 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:31-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:31-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:

मेजर टॅग पिन करा आणि 31 जसेच्या तसे कॉपी करण्यापूर्वी Docker Hub वर सध्याचा टॅग तपासा. latest भविष्यातील कोणत्याही docker compose pull वर तुम्हाला मेजर बाउंड्री ओलांडायला लावेल आणि Nextcloud त्याला सपोर्ट करत नाही.

डेटा डिरेक्टरी ही मुद्दामहून bind mount आहे, named volume नाही: बॅकअप टूल थेट पॉइंट करता येईल असा पाथ असणे हे नीटनेटकेपणापेक्षा जास्त महत्त्वाचे आहे. ती इमेजच्या 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 चेन पॅकेट पाहण्यापूर्वीच कार्यान्वित होतात. त्यामुळे, ufw काहीही म्हणत असला तरी, एक साधा 8080:80 Nextcloud ला विना-एनक्रिप्टेड स्वरूपात सार्वजनिक इंटरनेटवर उघडे करतो. लूपबॅकवर बाइंड केल्याने ते सार्वजनिक इंटरफेसपासून दूर राहते. त्यानंतर फायरवॉलला फक्त प्रॉक्सीला परवानगी द्यावी लागते. जर तुम्हाला 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 आणि त्यापुढील आवृत्त्यांवर, http2 on; जोडा. Ubuntu 24.04 मध्ये जुनी बिल्ड असल्याने तिथे listen 443 ssl http2; वापरले जाते. तुमची बिल्ड कोणता पर्याय स्वीकारते हे nginx -t द्वारे समजेल.

client_max_body_size आणि जास्त वेळ असलेले read timeouts यामुळे मोठ्या फाइल्स अपलोड होताना मध्येच बंद पडत नाहीत. proxy_request_buffering off मुळे फाइल आधी प्रॉक्सीच्या डिस्कवर साठवण्याऐवजी थेट स्ट्रीम केली जाते.

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

trusted_proxies आणि overwriteprotocol

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

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

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

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

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

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

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

Nextcloud चा डीफॉल्ट जॉब रनर AJAX आहे: जेव्हा कोणीतरी पेज लोड करते, तेव्हाच जॉब्स कार्यान्वित होतात. पहाटे 04:00 वाजता कोणीही ब्राउझिंग करत नसल्यामुळे, कचरा (trash) काढून टाकणे, जुन्या आवृत्त्या साफ करणे, प्रिव्ह्यू तयार करणे आणि फेडरेटेड रिट्राय (federated retries) यांसारखी कामे रखडतात. याचे पहिले लक्षण म्हणजे डेटा डिरेक्टरीचा आकार सतत वाढत राहणे. वरील 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 एका वेळी फक्त एकच प्रमुख आवृत्ती (major version) अपग्रेड करण्यास सपोर्ट करते. आवृत्ती 29 वरून थेट 31 वर जाणे योग्यरित्या पूर्ण होत नाही, ते Exception: Updates between multiple major versions and downgrades are unsupported. सह अपयशी ठरते आणि तुम्हाला maintenance mode मध्ये ठेवते.

Docker अपग्रेड करण्याची पद्धत अशी आहे: बॅकअप घ्या, app आणि cron या दोन्ही सर्व्हिसेसमधील टॅग 31 वरून 32 मध्ये बदला, त्यानंतर 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 तपासा, तसेच सर्व ॲप्स पुन्हा सुरू (enabled) झाले आहेत याची खात्री करा.

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

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

"Your data directory is readable by other users. Please change the permissions to 0770." बाइंड-माउंट केलेल्या डिरेक्टरीमध्ये group किंवा world read बिट्स सेट आहेत. sudo chmod 0770 /srv/nextcloud/data आणि sudo chown -R 33:33 /srv/nextcloud/data तपासा.

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

"Access through untrusted domain." विनंतीमधील hostname 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 वापरून खात्री करा.

Redirect loop, किंवा ॲडमिन ओव्हरव्ह्यूमध्ये "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 512MB." PHP_MEMORY_LIMIT वाढवा आणि कंटेनर पुन्हा तयार करा. यामुळे तुमच्या सिस्टिमच्या कमाल मर्यादेवर (worst-case ceiling) काय परिणाम होईल हे लक्षात ठेवा.

मोठ्या प्रमाणावर काम करताना येणाऱ्या अडचणी

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

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

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

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

एकदा का इन्स्टन्स खऱ्या वापरकर्त्यांना सेवा देऊ लागला की, Uptime Kuma चा वापर करा, जेणेकरून सिंक क्लायंटला समजण्याआधी तुम्हाला डाउनटाइमची माहिती मिळेल. प्रायव्हेट क्लाउड तुमच्या स्वतःच्या मेल सर्व्हरसोबत उत्तम काम करते. जर तुम्हाला सेवा हाताने जोडायच्या नसतील, तर Cloudron, CasaOS आणि Coolify या प्लॅटफॉर्मची तुलना करा, जे हे काम तुमच्यासाठी करतात. जर तुमच्या यादीत सेल्फ-होस्टेड सर्च इंजिन असेल, तर वरील समस्यांपेक्षा वेगळ्या प्रकारच्या समस्यांची अपेक्षा ठेवा: 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 रिव्हर्स प्रॉक्सीच्या मागे मोठ्या फाईल्स अपलोड करताना अपयश का येते?

प्रॉक्सीवरील दोन सेटिंग्ज सहसा यासाठी कारणीभूत असतात: client_max_body_size ची डीफॉल्ट 1 MB मर्यादा विनंती अर्धवट कापते, आणि proxy_read_timeout / proxy_send_timeout ची कमी व्हॅल्यू मोठ्या ट्रान्सफरला मध्येच थांबवते. दोन्ही व्हॅल्यूज पुरेशा वाढवा, proxy_request_buffering off ला स्पूलऐवजी स्ट्रीमवर सेट करा आणि ॲप कंटेनरवरील 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 प्रत्येक अपग्रेडमध्ये फक्त एक मेजर व्हर्जन सपोर्ट करते. व्हर्जन वगळल्यास Updates between multiple major versions and downgrades are unsupported. एरर येते आणि इन्स्टन्स मेंटेनन्स मोडमध्ये अडकतो. बॅकअप घ्या, app आणि cron या दोन्ही सर्व्हिसेसचे टॅग एक मेजर व्हर्जनने वाढवा, docker compose pull && docker compose up -d करा, occ status ने पडताळा आणि त्यानंतर ही प्रक्रिया पुन्हा करा.