VPS پر Docker کے ساتھ Nextcloud کیسے انسٹال کریں

آپ دراصل کیا بنا رہے ہیں

یہ گائیڈ Docker Compose کے ساتھ ایک VPS پر Nextcloud چلاتی ہے، اس کے آگے Let's Encrypt TLS لگاتی ہے، اور ایک ایسا بیک اپ سیٹ اپ کرتی ہے جو واقعی بحال (restore) ہوتا ہے۔ چار کنٹینرز اور ایک پراکسی: لوپ بیک پر لسن کرنے والی آفیشل nextcloud امیج، تمام فائل میٹا ڈیٹا رکھنے والی Postgres، فائل لاکس کو سنبھالنے والی Redis، Nextcloud امیج کی ایک دوسری کاپی جو صرف cron لوپ چلاتی ہے، اور ہوسٹ پر موجود nginx جو ان سب کے آگے TLS ٹرمینیشن کرتی ہے۔ انسٹالیشن خود 20 منٹ لیتی ہے، اور یہ وہ حصہ نہیں جو اہمیت رکھتا ہے۔ پہلے گھنٹے میں کیے گئے دو فیصلے یہ طے کرتے ہیں کہ آیا ایک سال بعد بھی آپ کی فائلیں آپ کے پاس ہوں گی یا نہیں: SQLite کے بجائے ایک حقیقی ڈیٹا بیس، اور ایک ایسا بیک اپ جو ڈیٹا ڈائریکٹری، ڈیٹا بیس اور config.php کو ایک مستقل سیٹ کے طور پر محفوظ کرے۔

یہ گائیڈ فرض کرتی ہے کہ آپ کے پاس Ubuntu 24.04 LTS یا Debian 13 موجود ہے، Docker کا Compose v2 پلگ ان Docker کی اپنی ریپوزٹری سے انسٹال شدہ ہے، اور ایک DNS A ریکارڈ (علاوہ ازیں AAAA اگر آپ کے پاس IPv6 ہے) پہلے سے cloud.example.com کو VPS کی طرف پوائنٹ کر رہا ہے۔ اس سب کے لیے ایک ایسے سرور کی ضرورت ہے جس پر آپ کا کنٹرول ہو، کسی اور کے SaaS پر TLS ٹرمینیشن اور ڈیٹا بیس ڈمپ کرنے کا کوئی طریقہ نہیں ہے۔

سائزنگ: میموری اصل میں کہاں استعمال ہوتی ہے

Nextcloud کی میموری کا استعمال بنیادی طور پر تین چیزوں پر منحصر ہے، اور ان میں سے کوئی بھی بذات خود "Nextcloud" نہیں ہے۔

PHP ورکرز۔ -apache امیج ہر بیک وقت آنے والی درخواست کو ایک ورکر پروسیس کے ذریعے پورا کرتی ہے جس میں PHP انٹرپریٹر موجود ہوتا ہے۔ ہر ورکر PHP_MEMORY_LIMIT تک بڑھ سکتا ہے اس سے پہلے کہ PHP درخواست کو ختم کر دے۔ آپ کی بدترین صورتحال میں درکار میموری تقریباً بیک وقت درخواستوں کی تعداد × میموری کی حد ہوتی ہے، اور ڈیسک ٹاپ سنک کلائنٹ فی صارف کئی متوازی کنکشن کھولتا ہے۔ کنکرنسی (concurrency)، نہ کہ صارفین کی تعداد، حد کا تعین کرتی ہے۔

ڈیٹا بیس۔ Postgres ہر کنکشن کے لیے ایک بیک اینڈ فورک کرتا ہے اور شیئرڈ بفرز کو میموری میں رکھتا ہے۔ اس کا ورکنگ سیٹ فائلوں کی تعداد کے ساتھ بڑھتا ہے، نہ کہ بائٹس کی تعداد کے ساتھ: oc_filecache میں فی صارف فی فائل ایک قطار ہوتی ہے۔ ایک لاکھ چھوٹی فائلیں، سو بڑی فائلوں کے مقابلے میں ڈیٹا بیس پر زیادہ بوجھ ڈالتی ہیں۔

پریویو جنریشن۔ تھمب نیل بنانے کے لیے سورس امیج کو مکمل ریزولیوشن میں میموری میں ڈیکوڈ کیا جاتا ہے۔ ویڈیو پریویوز ffmpeg کا استعمال کرتے ہیں۔ occ preview:generate-all کو چلانے سے یہ اسپائک بار بار، ایک کے بعد ایک ہوتی ہے، اور یہ چھوٹے VPS کو OOM کِلر (Out of Memory killer) کی زد میں لانے کا سب سے عام طریقہ ہے۔

Redis نسبتاً کم میموری لیتا ہے۔ بعد میں آپ جو بھی چیز شامل کرتے ہیں، جیسے Collabora، فل ٹیکسٹ سرچ، یا اینٹی وائرس اسکینر، وہ اپنی الگ میموری کے ساتھ ایک علیحدہ رہائشی سروس ہوتی ہے، اور اسے فعال کرنے سے پہلے آپ کے سائزنگ پلان میں شامل ہونا چاہیے۔

اگر آپ کے پاس RAM کم ہے تو یہ اقدامات کریں: PHP_MEMORY_LIMIT کو کم کریں، preview_max_x / preview_max_y / preview_max_filesize_image کو محدود کریں، enabledPreviewProviders کو صرف ان فارمیٹس تک محدود کریں جنہیں آپ واقعی براؤز کرتے ہیں، اور trashbin_retention_obligation اور versions_retention_obligation کو سیٹ کریں تاکہ ڈیٹا ڈائریکٹری خاموشی سے آپ کی فائلوں کے سائز سے کئی گنا زیادہ نہ بڑھ جائے۔ ایک swap فائل شامل کریں۔ Swap سست ہوتا ہے، لیکن اپ گریڈ کے دوران OOM کِل (میموری ختم ہونے پر عمل کا بند ہونا) کہیں زیادہ برا ہے۔

SQLite کیوں ناکام ہوتا ہے

Nextcloud میں SQLite کی سپورٹ موجود ہے اور اس کی آفیشل امیج اسے بخوشی استعمال کر لیتی ہے۔ آپ ایسا نہ کریں۔ SQLite ڈیٹا بیس لیول پر لاک لگا کر writes کو ترتیب دیتا ہے: یعنی پوری فائل کے لیے ایک وقت میں صرف ایک writer۔ Nextcloud مسلسل لکھتا رہتا ہے، جیسے فائل لاکس، ایکٹیویٹی روز، کیشے اینٹریز، جاب اسٹیٹ، اور ایک ڈیسک ٹاپ کلائنٹ جو ڈائریکٹری ٹری کو سنک کر رہا ہو، وہ ایک ساتھ کئی متوازی درخواستیں بھیجتا ہے۔ اس پیٹرن کے تحت آپ کو 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 کو ایک ساتھ والی .env فائل میں 600 موڈ کے ساتھ رکھیں۔

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:

میجر ٹیگ کو پن (pin) کریں اور 31 کو ہو بہو کاپی کرنے سے پہلے Docker Hub پر موجودہ ٹیگ چیک کریں۔ latest آپ کو مستقبل میں کسی docker compose pull پر میجر باؤنڈری کے پار لے جائے گا، اور Nextcloud اس کی سپورٹ نہیں کرتا۔

ڈیٹا ڈائریکٹری کو جان بوجھ کر bind mount کیا گیا ہے، نہ کہ named volume: ایک ایسا پاتھ جس کی طرف آپ براہ راست بیک اپ ٹول کا رخ کر سکیں، صفائی سے زیادہ اہمیت رکھتا ہے۔ اسے امیج کے www-data UID اور Nextcloud کی مطلوبہ اجازتوں (permissions) کے ساتھ بنائیں:

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 غیر انکرپٹڈ Nextcloud کو پبلک انٹرنیٹ پر ڈال دیتا ہے، قطع نظر اس کے کہ ufw کیا کہتا ہے۔ لوپ بیک (loopback) پر بائنڈ کرنے سے یہ پبلک انٹرفیس سے دور رہتا ہے۔ پھر فائر وال کو صرف پراکسی کو اجازت دینی پڑتی ہے، اور اگر آپ SSH کو پورے انٹرنیٹ کے لیے کھلا نہیں چھوڑنا چاہتے، تو سیلف ہوسٹڈ 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 کو اسے rewrite کرنے دیں۔ 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 ری ڈائریکٹ شامل کرتا ہے، اور ایک systemd ٹائمر انسٹال کرتا ہے جو 90 دن کے سرٹیفکیٹ کو رینیو کرتا ہے۔ اس کی موجودگی کی تصدیق systemctl list-timers | grep certbot سے کریں، کیونکہ جو رینیول ٹائمر کبھی فعال نہیں کیا گیا وہ 90 دن کا ایک فیوز (fuse) ثابت ہو سکتا ہے۔

پراکسی بلاک خود یہ ہے:

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 اور طویل ریڈ ٹائم آؤٹس وہ چیزیں ہیں جو بڑی اپ لوڈز کو درمیان میں رکنے سے روکتی ہیں۔ proxy_request_buffering off اپ لوڈ کو پراکسی کی ڈسک پر پہلے مکمل فائل spool کرنے کے بجائے براہ راست اسٹریم کرتا ہے۔

ایک ایپ کے لیے ہوسٹ پر 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:// URLs جاری کرتا ہے؛ پراکسی انہیں 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 کو سپوف (spoof) کر سکتا ہے؛ اگر غلط سیٹ کریں گے تو ہر لاگ ان گیٹ وے ایڈریس سے آتا ہوا دکھائی دے گا، brute-force پروٹیکشن ایک ہی وقت میں آپ کی پوری انسٹالیشن کو بلاک کر دے گی، اور ایڈمن اوور ویو میں یہ پیغام نظر آئے گا: "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

OVERWRITECLIURL کرون (cron) کنٹینر کے لیے اہم ہے، جس کے پاس ہوسٹ نیم کا اندازہ لگانے کے لیے کوئی آنے والی درخواست نہیں ہوتی۔ اس کے بغیر، بیک گراؤنڈ جابز localhost کے لنکس بناتی ہیں اور ای میل نوٹیفکیشنز ناقابل استعمال URLs بھیجتی ہیں۔

پس منظر کے کام: cron، نہ کہ AJAX

Nextcloud کا ڈیفالٹ جاب رنر AJAX ہے: کام تب انجام پاتے ہیں جب کوئی صارف صفحہ لوڈ کرتا ہے۔ رات 04:00 بجے کوئی براؤزنگ نہیں کر رہا ہوتا، اس لیے کوڑا کرکٹ ختم کرنے، ورژنز کی صفائی، پیش نظارہ (previews) اور فیڈریٹڈ ری ٹرائز رک جاتے ہیں، اور اس کی پہلی علامت یہ ہوتی ہے کہ ڈیٹا ڈائریکٹری کا سائز بڑھنا بند نہیں ہوتا۔ اوپر دیا گیا 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 بنانا فائدہ مند ہے۔

بیک اپ: تین چیزیں، یا کچھ بھی نہیں

صرف فائل سسٹم کا بیک اپ ایک ٹوٹی ہوئی instance کو بحال کرتا ہے۔ ڈیٹا ڈائریکٹری میں بائٹس موجود ہوتے ہیں؛ Postgres فائل کیش، شیئرز، صارفین، اور ایپ کی حالت کو سنبھالتا ہے؛ config.php میں ڈیٹا بیس کی اسناد، instance ID اور پاس ورڈ سالٹ محفوظ ہوتے ہیں۔ ڈیٹا بیس کے بغیر فائلیں بحال کریں تو Nextcloud انہیں دیکھ نہیں سکتا۔ config.php کے بغیر ڈیٹا بیس بحال کریں تو یہ ڈیٹا بیس کو کھول نہیں سکتا۔ ایک پرانے ڈیٹا بیس کو نئی ڈیٹا ڈائریکٹری پر بحال کرنے سے آپ کو ایسے شیئرز ملیں گے جو ان فائلوں کی طرف اشارہ کر رہے ہوں گے جو منتقل ہو چکی ہیں۔

ایک quiesced instance سے ان تینوں کا بیک اپ لیں:

#!/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/

Maintenance mode وہ عمل ہے جو ڈمپ اور فائل کاپی کو ایک دوسرے کے ساتھ ہم آہنگ کرتا ہے۔ اسے چھوڑ دیں تو آپ بالآخر ایسا ڈیٹا بیس کیپچر کر لیں گے جو ایسی فائل کا حوالہ دے رہا ہوگا جہاں تک rsync ابھی نہیں پہنچا تھا۔ نوٹ کریں کہ اسکرپٹ ٹائم اسٹیمپ والے ڈیٹا بیس ڈمپ تو رکھتی ہے لیکن ڈیٹا ڈائریکٹری کا صرف ایک رولنگ مرر رکھتی ہے، rsync --delete ہر رن پر اسے اوور رائٹ کر دیتا ہے، لہذا صرف تازہ ترین ڈمپ ہی فائل کاپی کے ساتھ مطابقت رکھتا ہے۔

پھر اسے سرور سے باہر منتقل کریں۔ جو بیک اپ اسی VPS پر موجود ہو جس کا وہ بیک اپ لے رہا ہے، وہ صرف ایک کاپی ہے، بیک اپ نہیں۔ restic کو آبجیکٹ اسٹوریج یا دوسرے ہوسٹ پر استعمال کرنا معمول کا جواب ہے، اور اس کی ڈیڈپلیکیشن (deduplication) ڈیٹا ڈائریکٹری کو رات کے وقت بننے والے tarball سے کہیں بہتر طریقے سے سنبھالتی ہے۔ ریپوزٹری انیشلائزیشن سے لے کر نائٹلی ٹائمر اور بحالی کی مشق تک، مکمل سیٹ اپ off-box VPS backups with restic میں موجود ہے۔

بحالی صرف الٹا عمل نہیں ہے۔ ایک تازہ شروع ہونے والا اسٹیک انسٹالر چلاتا ہے اور ایک بالکل نیا config.php، ایک نئی instance 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 ایک وقت میں صرف ایک میجر ورژن کے اپ گریڈ کو سپورٹ کرتا ہے۔ 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 کو چیک کریں کہ آیا ایپس دوبارہ فعال ہو گئی ہیں۔

دو اصول جو آپ کو بچاتے ہیں: ایک وقت میں ایک میجر ورژن بڑھائیں، تصدیق کریں، پھر اگلا ورژن بڑھائیں۔ اور کبھی بھی app سروس کے ٹیگ کو cron میں تبدیلی کیے بغیر اپ ڈیٹ نہ کریں، کیونکہ ایک ہی ڈیٹا بیس پر دو مختلف Nextcloud ورژنز کا ہونا ڈیٹا کرپشن کا باعث بنتا ہے۔

وہ غلطیاں جو آپ کو درحقیقت نظر آئیں گی

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mount شدہ ڈائریکٹری میں 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." bind mount کسی ایسی جگہ اشارہ کر رہا ہے جہاں Nextcloud کبھی initialize نہیں ہوا، پاتھ میں ٹائپنگ کی غلطی ہے، یا کسی چلتے ہوئے instance کے نیچے ایک نئی خالی ڈائریکٹری آ گئی ہے۔ تصدیق کریں کہ host پاتھ volume لائن سے مطابقت رکھتا ہے۔

"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 پر کسی چیز تک نہیں پہنچ سکا۔ یا تو کنٹینر ابھی initialize ہو رہا ہے (docker compose logs app چیک کریں)، یہ بند ہو چکا ہے (docker compose ps)، یا publish لائن proxy_pass پورٹ سے مطابقت نہیں رکھتی۔ ss -ltnp | grep 8080 کے ساتھ تصدیق کریں۔

ایک redirect loop، یا admin overview میں "insecure" انتباہات۔ OVERWRITEPROTOCOL: https غائب ہے، یا TRUSTED_PROXIES میں Docker گیٹ وے سب نیٹ شامل نہیں ہے۔ اوپر دیا گیا پراکسی سیکشن دیکھیں۔

LockedException: "files/..." is locked۔ REDIS_HOST سیٹ ہونے کے ساتھ، امیج Redis کو locking backend کے طور پر کنفیگر کرتی ہے اور پرانے لاکس شاذ و نادر ہی ہوتے ہیں۔ اس کے بغیر، لاکس ڈیٹا بیس ٹیبل oc_file_locks میں رہتے ہیں اور لکھتے وقت منقطع ہونے والی درخواست پیچھے قطاریں (rows) چھوڑ دیتی ہے۔ تصدیق کریں کہ Redis واقعی استعمال میں ہے، ہاتھ سے لاک روز (lock rows) صاف کرنے سے پہلے 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 پر volume کو بڑھانے کے لیے resize اور پھر filesystem کو بڑھانا پڑتا ہے، اور 100 فیصد بھر جانے کے بعد یہ عمل انتہائی تکلیف دہ ہوتا ہے، اس لیے disk usage پر ابھی الرٹ لگائیں، بعد کے لیے نہ چھوڑیں۔

دوسری رکاوٹ oc_filecache ہے۔ row count بڑھنے کے ساتھ فائل لسٹنگ اور سنک اسکین سست ہو جاتے ہیں، اس کا حل ڈیٹا بیس پر کام کرنا ہے: Postgres کو تیز اسٹوریج پر رکھیں، اسے کافی shared memory استعمال کرنے دیں، اور retention settings کے ذریعے کوڑا کرکٹ اور پرانے ورژنز کو صاف کرتے رہیں بجائے اس کے کہ انہیں ہمیشہ کے لیے جمع ہونے دیں۔

تیسری رکاوٹ preview generation کا دیگر تمام کاموں کے ساتھ مقابلہ ہے۔ چھوٹے سرور پر، preview providers کو محدود رکھیں اور کام کے اوقات کے دوران کبھی بھی occ preview:generate-all نہ چلائیں۔ اگر آپ کے اسٹوریج کا بڑا حصہ فون کی کیمرہ رول ہے، تو thumbnail بنانے کا کام کسی مخصوص فوٹو سرور پر ہونا چاہیے، اور PhotoPrism اور Immich کا RAM، فون ایپس اور بیک اپ کمانڈز کے لحاظ سے موازنہ اس بات کا احاطہ کرتا ہے کہ Nextcloud باکس کے مقابلے میں ان میں سے ہر ایک کی کیا قیمت ہے۔

اس سے آگے، سچ یہ ہے کہ اضافی فیچرز کو اپنے الگ سرور کی ضرورت ہوتی ہے۔ Collabora اور full-text search الگ الگ رہائشی سروسز ہیں جن کے اپنے میموری پروفائلز ہیں، اور انہیں اسی باکس پر رکھنا جہاں آپ کی فائلوں کی واحد کاپی موجود ہے، بغیر کسی فائدے کے failure domain کو بڑا کر دیتا ہے۔ اگر آپ کو براؤزر میں دستاویز کی ایڈیٹنگ درکار ہے، تو OnlyOffice اور Collabora کے درمیان وینڈر کی RAM کی کم از کم حد اور کنکشن کی حدود یہ طے کرتی ہیں کہ 2 سے 4 GB کا VPS کسے سنبھال سکتا ہے۔ جب volume کا سائز مناسب نہ رہے تو فائل اسٹوریج کو S3-compatible پرائمری اسٹوریج پر منتقل کریں، اور یاد رکھیں کہ اس سے بیک اپ آسان نہیں بلکہ مشکل ہو جاتا ہے: ڈیٹا بیس اب بھی میٹا ڈیٹا رکھتا ہے، اور اسے bucket کے ساتھ ہم آہنگ ہو کر dump کیا جانا چاہیے۔

جب instance حقیقی صارفین کو سروس فراہم کر رہا ہو، تو اس کے آگے Uptime Kuma لگائیں تاکہ سنک کلائنٹس سے پہلے آپ کو downtime کا علم ہو سکے۔ ایک پرائیویٹ کلاؤڈ آپ کے اپنے میل سرور کے ساتھ بہترین کام کرتا ہے، اور اگر آپ سروسز کو دستی طور پر جوڑنا نہیں چاہتے، تو Cloudron، CasaOS اور Coolify ان پلیٹ فارمز کا موازنہ کرتے ہیں جو یہ کام آپ کے لیے کرتے ہیں۔ اگر اس فہرست میں اگلا نمبر self-hosted سرچ انجن کا ہے، تو اوپر بیان کردہ مسائل سے مختلف قسم کے مسائل کی توقع رکھیں: SearXNG کے 429 ایررز یا تو اس کے اپنے rate limiter کی وجہ سے ہوتے ہیں یا upstream انجنز کی جانب سے آپ کے VPS IP کو بلاک کرنے کی وجہ سے، اور صرف لاگز ہی آپ کو بتا سکتے ہیں کہ اصل وجہ کیا ہے۔

FAQ

کیا میں Postgres کے بجائے SQLite پر Nextcloud چلا سکتا ہوں؟

آپ ایسا کر سکتے ہیں اور official image آپ کو اس کی اجازت دے گی، لیکن ایک ڈیسک ٹاپ سنک کلائنٹ کی جانب سے متوازی درخواستیں بھیجنے پر آپ کو SQLSTATE[HY000]: General error: 5 database is locked اور HTTP 500 کی غلطیاں ملیں گی۔ SQLite پورے ڈیٹا بیس پر write lock لگا دیتا ہے، جبکہ Nextcloud مسلسل فائل لاکس، ایکٹیویٹی روز اور جاب اسٹیٹ جیسی چیزیں لکھتا رہتا ہے۔ Postgres یا MariaDB سے شروعات کریں؛ occ db:convert-type موجود تو ہے لیکن یہ لائیو ڈیٹا پر ایک طویل اور سب کچھ یا کچھ نہیں (all-or-nothing) والا مائیگریشن عمل ہے۔

Nextcloud VPS کو اصل میں کتنی RAM درکار ہوتی ہے؟

سائز کا تعین concurrency (ہم وقتی درخواستوں) کے لحاظ سے کریں، نہ کہ صارفین کی تعداد کے لحاظ سے۔ بدترین صورت میں resident memory کا تخمینہ تقریباً ہم وقتی درخواستوں کی تعداد کو PHP_MEMORY_LIMIT سے ضرب دے کر لگایا جاتا ہے، اس میں Postgres کے shared buffers اور فی کنکشن ایک بیک اینڈ کا اضافہ کریں، نیز preview generation کے دوران ہونے والے spikes کو بھی شامل کریں۔ 2 GB کا سرور ایک چھوٹے گھریلو انسٹینس کے لیے کافی ہے اگر آپ previews کو محدود کر دیں اور swap کا استعمال کریں؛ اگر آپ Collabora یا full-text search شامل کرتے ہیں تو آپ کو اضافی سروسز کے لیے مزید وسائل درکار ہوں گے۔

nginx reverse proxy کے پیچھے بڑی فائلیں اپ لوڈ کیوں ناکام ہو جاتی ہیں؟

پراکسی پر موجود دو سیٹنگز عام طور پر اس کی وجہ ہوتی ہیں: client_max_body_size کو 1 MB کی ڈیفالٹ ویلیو پر چھوڑنے سے درخواست کٹ جاتی ہے، اور proxy_read_timeout / proxy_send_timeout کی کم ویلیوز طویل ٹرانسفرز کو درمیان میں ہی ختم کر دیتی ہیں۔ دونوں کو مناسب حد تک بڑھائیں، proxy_request_buffering off کو spool کے بجائے stream پر سیٹ کریں، اور ایپ کنٹینر پر PHP_UPLOAD_LIMIT کو اس کے مطابق بڑھا دیں۔

Nextcloud ری ڈائریکٹ لوپ میں کیوں پھنس جاتا ہے یا reverse proxy کے بارے میں وارننگ کیوں دیتا ہے؟

کنٹینر کو 127.0.0.1 پر nginx نظر نہیں آتا، اسے Docker bridge گیٹ وے نظر آتا ہے جو 172.x میں کہیں ہوتا ہے۔ جب یہ ایڈریس TRUSTED_PROXIES میں موجود نہ ہو تو X-Forwarded-Proto: https ہیڈر کو نظر انداز کر دیا جاتا ہے، Nextcloud http:// URLs جاری کرتا ہے، اور پراکسی انہیں واپس بھیج دیتی ہے۔ TRUSTED_PROXIES کو اصل برج سب نیٹ پر سیٹ کریں اور OVERWRITEPROTOCOL: https کو پن (pin) کریں۔

کیا میں Nextcloud کو 29 سے براہ راست 31 پر اپ گریڈ کر سکتا ہوں؟

نہیں۔ Nextcloud فی اپ گریڈ صرف ایک میجر ورژن کی سپورٹ کرتا ہے، اور ورژن چھوڑنے (skipping) کی صورت میں عمل Updates between multiple major versions and downgrades are unsupported. پر رک جاتا ہے اور انسٹینس maintenance mode میں چلا جاتا ہے۔ بیک اپ لیں، app اور cron دونوں سروسز پر ٹیگ کو ایک میجر ورژن آگے بڑھائیں، docker compose pull && docker compose up -d کریں، occ status کے ساتھ تصدیق کریں، اور پھر یہی عمل دہرائیں۔