VPS پر Nextcloud Docker Compose کے ساتھ کیسے چلائیں

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

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

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

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

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

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

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

پریویو جنریشن۔ تھمب نیل بنانے کے لیے سورس امیج کو مکمل ریزولوشن پر میموری میں ڈی کوڈ کیا جاتا ہے۔ ویڈیو پریویوز ffmpeg کو کال کرتے ہیں۔ occ preview:generate-all چلانا اس میموری کے اچھال کو بار بارا، لگاتار پیدا کرتا ہے، اور یہ ایک چھوٹے VPS کو OOM کلر کی طرف دھکیلنے کا واحد سب سے عام طریقہ ہے۔

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 رائٹ آپریشنز کو ڈیٹابیس کی سطح کی لاک کے ساتھ سیریلائز کرتا ہے: ایک وقت میں صرف ایک رائٹر، پورے فائل کے لیے۔ Nextcloud مسلسل رائٹ کرتا ہے — فائل لاکس، ایکٹیویٹی قطار، کیشے انٹریز، جاب اسٹیٹ — اور ایک سادہ ڈیسک ٹاپ کلائنٹ جو ڈائریکٹری ٹری سنک کر رہا ہے، کئی متوازی درخواستیں بھیجتا ہے۔ اس پیٹرن کے تحت آپ کو SQLSTATE[HY000]: General error: 5 database is locked اور HTTP 500s ملیں گے، اور یہ ناکامی بالکل اسی وقت ظاہر ہوتی ہے جب انسٹنس استعمال کے قابل ہونا شروع ہوتا ہے۔

بعد میں تبدیلی occ db:convert-type کے ساتھ ممکن ہے، لیکن یہ لائیو ڈیٹاسیٹ پر ایک طویل، آل-اور-نتھنگ مائگریشن ہے۔ شروعات Postgres یا MariaDB کے ساتھ کریں۔

Compose فائل

اسے /srv/nextcloud/compose.yaml میں رکھیں، اور رازداری کی معلومات کو ہم مرتبہ .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:

بڑا ٹیگ مقرر کریں اور 31 کو عیناً نقل کرنے سے پہلے Docker Hub پر موجودہ ٹیگ کی جانچ کریں۔ latest کسی مستقبل کے docker compose pull میں آپ کو بڑے ورژن کی حد سے پار لے جائے گا، اور Nextcloud اس کی حمایت نہیں کرتا۔

ڈیٹا ڈائریکٹری جان بوجھ کر ایک bind mount ہے، named volume نہیں: ایک ایسا راستہ جسے آپ براہ راست بیک اپ ٹول کی طرف اشارہ کر سکیں، صفائی سے زیادہ قیمتی ہے۔ اسے image کے 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 کو بغیر خفیہ کاری کے عوامی انٹرنیٹ پر ظاہر کر دیتا ہے۔ loopback سے binding اسے عوامی انٹرفیس سے دور رکھتی ہے۔ پھر فائر وال کو صرف پراکسی کی اجازت دینی ہوتی ہے — اور اگر آپ SSH کو پورے انٹرنیٹ پر کھلا نہیں چھوڑنا چاہتے، تو VPS تک self-hosted WireGuard VPN کے ذریعے رسائی آپ کو پورٹ 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 پر نظر رکھیں۔ پہلا بوٹ پور ایپلیکیشن کے درخت کو volume میں نقل کرتا ہے اور انسٹالر چلاتا ہے؛ یہ عمل مکمل ہونے تک کنٹینر کوئی جواب نہیں دیتا۔

TLS اور ریورس پراکسی

nginx اور certbot کو ڈسٹرو سے انسٹال کریں۔ port 80 پر ایک سادہ سرور بلاک بنائیں جس میں درست server_name ہو، پھر 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 ریڈائریکٹ شامل کرتا ہے، اور ایک systemd ٹائمر انسٹال کرتا ہے جو 90 دن کا سرٹیفکیٹ تجدید کرتا ہے۔ اس کے موجود ہونے کی تصدیق 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 اور لمبے ریڈ ٹائم آؤٹس وہ چیزیں ہیں جو بڑے اپلوڈز کو آدھے راستے میں مرنے سے روکتی ہیں۔ proxy_request_buffering off اپلوڈ کو سیدھے اسٹریم کرتا ہے بجائے اس کے کہ پورا فائل پہلے پراکسی کی ڈسک پر اسپول کرے۔

ہوسٹ پر nginx ایک ایپ کے لیے سب سے سادہ کام کرنے والی چیز ہے۔ اگر Nextcloud کو VPS دوسرے کنٹینرز کے ساتھ شیئر کرنا ہے، تو متعدد ایپس کے لیے Docker Compose ریورس پراکسی کے طور پر Traefik چلانا روٹنگ اور سرٹیفکیٹ جاری کرنے کو کنٹینر لیبلز میں منتقل کر دیتا ہے، اور وہی client_max_body_size اور ٹائم آؤٹ کے مسائل وہاں مڈل ویئر اور ٹرانسپورٹ سیٹنگز کے طور پر دوبارہ سامنے آتے ہیں۔

trusted_proxies اور overwriteprotocol

یہ وہ مقام ہے جہاں زیادہ تر خود میزبانی کردہ Nextcloud انسٹنسز غلطیاں کرتے ہیں، اور علامات کا سبب سے کوئی ظاہری تعلق نظر نہیں آتا۔

X-Forwarded-Proto: https کی قدر اس وقت ہی تسلیم کی جاتی ہے جب درخواست trusted_proxies میں درج کسی پتے سے آئے۔ جب اس کی قدر تسلیم نہیں کی جاتی، Nextcloud سمجھتا ہے کہ درخواست سادہ HTTP ہے اور http:// URLs پیدا کرتا ہے؛ پراکسی انہیں HTTPS پر بھیجتی ہے؛ براؤزر پیروی کرتا ہے؛ 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 کو جعلی بنا سکتا ہے؛ اسے غلط مقرر کریں تو ہر لاگ ان gateway پتے سے آنے کا ظاہر ہوگا، brute-force تحفظ آپ کی پوری انسٹنس کو ایک ساتھ بلاک کر دے گا، اور ایڈمن جائزہ یہ دکھائے گا "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

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

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

Nextcloud کا طے شدہ job runner AJAX ہے: کام کسی کے صفحہ لوڈ کرنے کے ضمنی اثر کے طور پر چلتے ہیں۔ 04:00 بجے کوئی براؤز نہیں کرتا، اس لیے trash کی میعاد، versions کی صفائی، previews اور federated retries رک جاتے ہیں، اور پہلا علامت یہ ہوتی ہے کہ data directory بڑھتا ہی رہتا ہے۔ اوپر دیا گیا cron سروس اسی volumes کے خلاف سرکاری /cron.sh loop چلاتی ہے۔ 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 ڈیٹا بیس کی اسناد، انسٹنس آئی ڈی اور پاس ورڈ سالٹ رکھتا ہے۔ ڈیٹا بیس کے بغیر فائلوں کو بحال کریں تو Nextcloud انہیں نہیں دیکھ سکتا۔ config.php کے بغیر ڈیٹا بیس بحال کریں تو وہ ڈیٹا بیس نہیں کھول سکتا۔ نئی ڈیٹا ڈائریکٹری کے خلاف پرانا ڈیٹا بیس بحال کریں تو آپ کو ایسے شیئرز ملیں گے جو ہٹی ہوئی فائلوں کی طرف اشارہ کریں گے۔

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

#!/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 پر موجود ہو جس کا وہ بیک اپ لے رہا ہے، وہ ایک کاپی ہے، بیک اپ نہیں۔ آبجیکٹ اسٹوریج یا دوسرے ہوسٹ کے خلاف restic معمول کا جواب ہے، اور اس کی ڈی ڈوپلیکیشن رات کی tarball سے بہتر طریقے سے ڈیٹا ڈائریکٹری کو سنبھالتی ہے۔ مکمل سیٹ اپ، ریپوزٹری کی شروعات سے لے کر رات کے ٹائمر اور بحالی کے مشق تک، restic کے ساتھ باکس سے باہر VPS بیک اپس میں ہے۔

بحالی محض اس کا الٹا نہیں ہے۔ نئی شروع ہونے والا اسٹیک انسٹالر چلاتا ہے اور ایک بالکل نیا config.php لکھتا ہے — نیا انسٹنس آئی ڈی اور پاس ورڈ سالٹ — اور اس نئی شناخت کے اوپر ڈمپ درآمد کرنے سے خراب سیشنز اور شیئر ٹوکنز بنتے ہیں۔ پرانی شناخت کو پہلے واپس رکھیں، اس ترتیب میں:

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 پر اسے ایک بار مشق کریں۔

اپ گریڈ: ایک وقت میں صرف ایک میجر ورژن

Nextcloud ایک وقت میں بالکل ایک میجر ورژن کی اپ گریڈ کی اجازت دیتا ہے۔ 29 سے 31 پر براہ راست جانا درست طریقے سے ناکام نہیں ہوتا — یہ Exception: Updates between multiple major versions and downgrades are unsupported. کے ساتھ ناکام ہوتا ہے اور آپ کو میینٹیننس موڈ میں چھوڑ دیتا ہے۔

Docker اپ گریڈ کا طریقہ یہ ہے: بیک اپ لیں، app اور cron سروسز دونوں میں ٹیگ کو 31 سے 32 میں ترمیم کریں، پھر docker compose pull && docker compose up -d، پھر docker compose logs -f app۔ امیج انٹری پوائنٹ موجودہ ڈیٹا کے مقابلے میں نئے کوڈ کی شناخت کرتا ہے اور خود 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." بائنڈ ماؤنٹ شدہ ڈائریکٹری میں group یا world read bits موجود ہیں۔ 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 نے کبھی ابتدائی ترتیب نہیں کی — راستے میں کوئی ٹائپو، یا کسی کام کرنے والے انسٹنس کے تحت ایک نیا خالی ڈائریکٹری تبدیل کر دیا گیا۔ چیک کریں کہ ہوسٹ پاتھ 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 پر کچھ نہیں پایا۔ یا تو کنٹینر ابھی ابتدائی حالت میں ہے (docker compose logs app چیک کریں)، یہ ختم ہو گیا (docker compose ps)، یا publish لائن proxy_pass پورٹ سے نہیں ملتی۔ ss -ltnp | grep 8080 سے تصدیق کریں۔

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

LockedException: "files/..." is locked۔ REDIS_HOST سیٹ ہونے کے ساتھ، امیج Redis کو لاکنگ بیک اینڈ کے طور پر ترتیب دیتا ہے اور پرانے لاکس نایاب ہوتے ہیں۔ اس کے بغیر، لاکس ڈیٹا بیس ٹیبل oc_file_locks میں رہتے ہیں اور درمیان تحریر میں ختم ہونے والی درخواست پیچھے صفیں چھوڑتی ہے۔ تصدیق کریں کہ Redis واقعی استعمال میں ہے — occ config:system:get memcache.locking کو Redis کلاس واپس کرنا چاہیے — اس سے پہلے کہ آپ لاک صفیں دستی طور پر صاف کریں۔

"The PHP memory limit is below the recommended value of 512MB." PHP_MEMORY_LIMIT بڑھائیں اور کنٹینر دوبارہ بنائیں۔ یاد رکھیں کہ یہ آپ کی بدترین صورت کی حد پر کیا اثر ڈالتا ہے۔

پیمانے پر بڑھنے پر کیا ٹوٹتا ہے

پہلی رکاوٹ ڈیٹا ڈائریکٹری کا حجم سے بڑھ کر والیوم کو بھر دینا ہے۔ VPS پر والیوم بڑھانا ایک ریزائز اور فائل سسٹم میں اضافہ ہے، اور اسے شیڈول پر کرنا 100% بھرے ہونے سے کہیں کم تکلیف دہ ہے — ڈسک استعمال پر اب الرٹ لگائیں، بعد میں نہیں۔

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

تیسری رکاوٹ پیش نظارہ جنریشن کا باقی سب چیزوں سے مقابلہ کرنا ہے۔ ایک چھوٹے باکس پر، پیش نظارہ فراہم کرنے والوں کو محدود رکھیں اور ورکنگ اورز کے دوران occ preview:generate-all کبھی نہ چلائیں۔

اس کے بعد، سچائی یہ ہے کہ اضافی اجزاء اپنی الگ مشین چاہتے ہیں۔ Collabora اور فل ٹیکسٹ سرچ الگ مستقل سروسز ہیں جن کے اپنے میموری پروفائلز ہوتے ہیں، اور انہیں اس باکس پر رکھنا جو آپ کی فائلوں کی واحد کاپی بھی رکھتا ہے، بغیر کسی فائدے کے فیلر ڈومین کو بڑا کر دیتا ہے۔ جب والیوم صحیح سائز نہ رہے تو فائل اسٹوریج کو S3-کمپیٹیبل پرائمری اسٹوریج میں منتقل کریں — اور نوٹ کریں کہ اس سے بیک اپ مشکل ہوتا ہے، آسان نہیں: ڈیٹا بیس اب بھی میٹا ڈیٹا رکھتا ہے، اور اسے بکٹ کے ساتھ ساتھ ڈمپ کیا جانا چاہیے۔

جب انسٹانس حقیقی صارفین کو سروس دے رہا ہو، تو اس کے سامنے Uptime Kuma لگائیں تاکہ آپ ڈاؤن ٹائم کا علم سنک کلائنٹس سے پہلے حاصل کر لیں۔ ایک پرائیویٹ کلاؤڈ اپنے میل سرور کے ساتھ اچھی طرح جوڑ کھاتا ہے، اور اگر آپ سروسز کو ہاتھ سے جوڑنا نہیں چاہتے، تو Cloudron, CasaOS and Coolify ان پلیٹ فارمز کا موازنہ کرتا ہے جو یہ کام آپ کے لیے کرتے ہیں۔

FAQ

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

ہاں، اور سرکاری امیج بھی اس کی اجازت دیتی ہے۔ لیکن ایک ہی ڈیسک ٹاپ سنک کلائنٹ متوازی درخواستیں بھیجنے پر SQLSTATE[HY000]: General error: 5 database is locked اور HTTP 500 کی خرابیوں کا شکار ہو جائے گا۔ SQLite پوری ڈیٹابیس پر رائٹ لاک لیتا ہے، اور Nextcloud مسلسل ڈیٹا لکھتا ہے — فائل لاکس، ایکٹیویٹی قطاروں، اور جاب کی حالت۔ Postgres یا MariaDB پر شروع کریں؛ occ db:convert-type موجود ہے لیکن یہ لائیو ڈیٹا پر ایک طویل اور آل-اور-نتھنگ مائگریشن ہے۔

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

صارفین کی تعداد نہیں، متوازی عمل کے لحاظ سے سائز کا تعین کریں۔ بدترین صورت میں resident میموری تقریباً متوازی درخواستوں کی تعداد کو PHP_MEMORY_LIMIT سے ضرب دینے کے برابر ہوتی ہے، اس کے علاوہ Postgres shared buffers اور ہر کنکشن کے لیے ایک بیک اینڈ، اور جو کچھ پریویو جنریشن بڑھ کر ہو۔ ایک 2 GB والا سسٹم ایک چھوٹا گھریلو انسٹنس چلا سکتا ہے بشرطیکہ آپ پریویوز پر حد لگائیں اور swap شامل کریں؛ Collabora یا فل-ٹیکسٹ سرچ شامل کریں تو آپ کو دوسرا سیٹ resident سروسز کے حساب سے سائز دینا ہوگا۔

nginx ریورس پراکسی کے پیچھے بڑے اپ لوڈز کیوں ناکام ہوتے ہیں؟

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

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

کنٹینر nginx کو 127.0.0.1 پر نہیں دیکھتا — وہ Docker برج گیٹ وے دیکھتا ہے، جو 172.x میں کہیں ہوتا ہے۔ جب وہ پتہ TRUSTED_PROXIES سے غائب ہو، تو X-Forwarded-Proto: https ہیڈر نظر انداز کر دیا جاتا ہے، Nextcloud http:// URLs خارج کرتا ہے، اور پراکسی انہیں واپس بھیج دیتا ہے۔ 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 سے تصدیق کریں، پھر دہرائیں۔