Jinsi ya kuendesha Nextcloud kwenye VPS na Docker

Unachojenga kwa hakika

Mwongozo huu unaendesha Nextcloud kwenye VPS kwa kutumia Docker Compose, unaweka Let's Encrypt TLS mbele yake, na kusanidi chelezo (backup) inayoweza kurejeshwa kikamilifu. Kuna kontena nne na proksi moja: picha rasmi ya nextcloud inayosikiliza kwenye loopback, Postgres inayohifadhi kila kipande cha metadata ya faili, Redis inayoshikilia kufuli za faili (file locks), nakala ya pili ya picha ya Nextcloud inayoendesha cron loop pekee, na nginx kwenye seva mwenyeji inayomalizia TLS mbele ya yote hayo. Usakinishaji wenyewe huchukua dakika ishirini, na siyo sehemu muhimu zaidi. Maamuzi mawili yaliyofanywa katika saa ya kwanza ndiyo huamua kama utakuwa na faili zako baada ya mwaka mmoja: hifadhidata halisi badala ya SQLite, na chelezo inayochukua saraka ya data, hifadhidata, na config.php kama seti moja thabiti.

Hii inachukulia kuwa unatumia Ubuntu 24.04 LTS au Debian 13, Docker Engine yenye Compose v2 plugin iliyosakinishwa kutoka kwenye hazina ya Docker yenyewe, na rekodi ya DNS A (pamoja na AAAA kama una IPv6) inayoelekeza cloud.example.com kwenye VPS. Yote haya yanahitaji seva unayoimiliki; hakuna njia ya kufanya TLS termination na database dump kwenye SaaS ya mtu mwingine.

Ukubwa: nini hasa kinachotumia kumbukumbu

Matumizi ya kumbukumbu ya Nextcloud hutawaliwa na mambo makuu matatu, na hakuna hata moja kati ya hayo linaloitwa "Nextcloud" kama lilivyo.

PHP workers. Picha ya -apache huhudumia kila ombi linaloingia kwa wakati mmoja kutoka kwa mchakato wa worker unaoshikilia PHP interpreter. Kila worker inaweza kukua hadi PHP_MEMORY_LIMIT kabla ya PHP kusitisha ombi hilo. Kumbukumbu yako ya juu zaidi inayotumiwa (resident memory) ni takriban maombi ya wakati mmoja × kikomo cha kumbukumbu, na programu ya kusawazisha (sync client) ya kompyuta hufungua miunganisho kadhaa sambamba kwa kila mtumiaji. Idadi ya maombi ya wakati mmoja, si idadi ya watumiaji, ndiyo huweka kikomo cha juu.

Hifadhidata (Database). Postgres hutengeneza backend kwa kila muunganisho na kuhifadhi shared buffers kwenye kumbukumbu. Kiasi cha kumbukumbu kinachohitajika hukua kulingana na idadi ya faili, si idadi ya baiti: oc_filecache hubeba safu moja kwa kila faili kwa kila mtumiaji. Faili laki moja ndogo ni mzigo mkubwa zaidi kwa hifadhidata kuliko faili mia moja kubwa.

Utengenezaji wa hakikisho (Preview generation). Kutengeneza thumbnail hufungua picha asilia kwenye kumbukumbu kwa ukubwa wake wote. Hakikisho za video hutumia ffmpeg. Kuendesha occ preview:generate-all hufanya kazi hiyo kwa mfululizo, na ndiyo njia ya kawaida inayoweza kusababisha VPS ndogo kupata OOM killer.

Redis hutumia kiasi kidogo cha kumbukumbu. Kila kitu unachoongeza baadaye, kama Collabora, full-text search, au antivirus scanner, ni huduma tofauti inayojitegemea na yenye matumizi yake ya kumbukumbu, hivyo ni lazima iingizwe kwenye mpango wako wa ukubwa kabla ya kuiwasha.

Mbinu za kutumia, ikiwa una RAM ndogo: punguza PHP_MEMORY_LIMIT, weka kikomo cha preview_max_x / preview_max_y / preview_max_filesize_image, punguza enabledPreviewProviders kwa miundo ya faili unayotumia kweli, na uweke trashbin_retention_obligation na versions_retention_obligation ili saraka ya data isikue kimyakimya hadi kufikia mara kadhaa ya ukubwa wa faili zako. Ongeza swap file. Swap ni polepole, lakini OOM kill katikati ya uboreshaji (upgrade) ni mbaya zaidi.

Kwa nini SQLite inafeli

Nextcloud inakuja na usaidizi wa SQLite na image rasmi itaitumia bila matatizo. Usifanye hivyo. SQLite hufunga uandishi kwa kutumia lock ya database nzima: mwandishi mmoja kwa wakati mmoja, kwa faili zima. Nextcloud huandika mara kwa mara, locks za faili, safu za shughuli, entries za cache, hali ya kazi, na desktop client moja inayosawazisha mti wa saraka hutoa maombi mengi sambamba. Chini ya muundo huo utapata SQLSTATE[HY000]: General error: 5 database is locked na HTTP 500s, na hitilafu hiyo hutokea pale tu instance inapoanza kuwa na manufaa.

Kubadilisha baadaye inawezekana kwa kutumia occ db:convert-type, lakini ni uhamiaji mrefu na wa hatari kwa data iliyo hai. Anza na Postgres au MariaDB.

Faili la Compose

Weka maudhui haya kwenye /srv/nextcloud/compose.yaml, huku siri zikiwa kwenye faili dada la .env lenye mode ya 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:

Funga toleo kuu (major tag) na uhakikishe toleo la sasa kwenye Docker Hub kabla ya kunakili 31 kama lilivyo. latest itakupeleka kwenye toleo kuu jipya katika docker compose pull yoyote ya baadaye, na Nextcloud haiauni hilo.

Saraka ya data ni bind mount, si named volume, kwa makusudi: njia unayoweza kuelekeza zana ya kuhifadhi nakala (backup tool) moja kwa moja ina thamani zaidi kuliko usafi wa faili. Iunde kwa kutumia UID ya www-data ya image hiyo na ruhusa (permissions) zinazohitajika na Nextcloud:

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

Zingatia uchapishaji wa port: 127.0.0.1:8080:80. Docker huchapisha port kwa kuandika sheria za DNAT zinazotathminiwa kabla ya chain ya INPUT ya ufw kuona pakiti hiyo; 8080:80 tupu huweka Nextcloud isiyosimbwa kwenye mtandao wa umma bila kujali sheria za ufw. Kufunga kwenye loopback huizuia isionekane kwenye interface ya umma. Kisha firewall inabidi tu iruhusu proxy, na ikiwa hutaki kuacha SSH wazi kwa mtandao mzima, kufikia VPS kupitia WireGuard VPN uliyojiwekea hukuruhusu kuondoa kabisa port 22 kutoka kwenye sheria za umma:

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

Ianzishe kwa kutumia docker compose up -d, kisha fuatilia docker compose logs -f app. Boot ya kwanza hunakili mti mzima wa programu kwenye volume na kuendesha kisakinishi; container haitojibu chochote hadi mchakato huo ukamilike.

TLS na reverse proxy

Sakinisha nginx na certbot kutoka kwenye hazina ya distro, tengeneza server block ya kawaida ya port-80 yenye server_name sahihi, kisha uruhusu certbot iandike upya usanidi huo. Mbinu za HTTP-01 challenge, kipima muda cha kusasisha (renewal timer), na njia za kushindwa (failure modes) zimefafanuliwa kikamilifu katika utoaji wa vyeti vya Let's Encrypt kwa kutumia certbot na nginx kwenye Ubuntu 24.04:

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

Certbot huongeza mistari ya ssl_certificate na redirect ya :80 → :443, na kusakinisha systemd timer inayosasisha cheti cha siku 90. Thibitisha kuwa ipo kwa kutumia systemctl list-timers | grep certbot; kipima muda cha kusasisha ambacho hakikuwahi kuwezeshwa ni sawa na bomu la muda la siku 90.

Proxy block yenyewe:

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;
    }
}

Kwenye nginx 1.25 na matoleo mapya zaidi, ongeza http2 on;. Ubuntu 24.04 inakuja na toleo la zamani zaidi ambapo mbadala wake ni listen 443 ssl http2;. nginx -t itakuambia ni ipi inayokubaliwa na toleo lako.

client_max_body_size na muda mrefu wa kusubiri (read timeouts) ndivyo vinavyozuia upload kubwa kukatika katikati. proxy_request_buffering off hutiririsha upload moja kwa moja badala ya kuhifadhi faili zima kwenye diski ya proxy kwanza.

nginx kwenye host ndiyo njia rahisi zaidi inayofanya kazi kwa programu moja. Ikiwa Nextcloud itashiriki VPS na container nyingine, kuendesha Traefik kama Docker Compose reverse proxy kwa programu nyingi huhamishia uelekezaji na utoaji wa vyeti kwenye lebo za container, na masuala yaleyale ya client_max_body_size na muda wa kusubiri hujitokeza tena huko kama middleware na mipangilio ya usafirishaji.

trusted_proxies na overwriteprotocol

Hapa ndipo matukio mengi ya Nextcloud yaliyojihifadhi (self-hosted) yanapokosea, na dalili zake huonekana kama hazihusiani na chanzo cha tatizo.

X-Forwarded-Proto: https huheshimiwa tu wakati ombi linapofika kutoka kwa anwani iliyoorodheshwa katika trusted_proxies. Wakati haijaheshimiwa, Nextcloud huamini kuwa ombi hilo ni HTTP ya kawaida na hutoa URL za http://; proxy huelekeza hizo kwenye HTTPS; kivinjari hufuata; Nextcloud hutoa http:// tena. Hiyo ndiyo mzunguko wa kuelekeza (redirect loop). OVERWRITEPROTOCOL: https hufunga scheme bila kujali hali hiyo.

Mtego katika TRUSTED_PROXIES ni kwamba anwani ambayo Nextcloud huiona siyo 127.0.0.1. nginx huendeshwa kwenye host na huunganisha kwenye port iliyochapishwa, kwa hivyo container huona gateway ya Docker bridge, kitu fulani katika 172.x. Tafuta subnet halisi:

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

Weka CIDR hiyo (au 172.16.0.0/12 inayohusika) katika TRUSTED_PROXIES. Ukiweka pana sana, mteja yeyote anaweza kughushi X-Forwarded-For; ukiweka vibaya, kila login itaonekana kama inatoka kwenye anwani ya gateway, ulinzi dhidi ya brute-force utazuia instance yako yote mara moja, na muhtasari wa admin utaonyesha "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

OVERWRITECLIURL ni muhimu kwa container ya cron, ambayo haina ombi linaloingia la kutolea hostname. Bila hiyo, kazi za usuli (background jobs) hutengeneza viungo vya localhost na arifa za barua pepe hutuma URL zisizoweza kutumika.

Kazi za usuli: cron, siyo AJAX

Kimbiaji cha kazi chaguo-msingi cha Nextcloud ni AJAX: kazi hutekelezwa kama matokeo ya mtumiaji kupakia ukurasa. Hakuna mtu anayevinjari saa 04:00, kwa hivyo ufutaji wa takataka, usafishaji wa matoleo, hakikisho (previews) na majaribio ya federated hushindwa, na dalili ya kwanza ni saraka ya data ambayo haachi kukua. Huduma ya cron hapo juu huendesha kitanzi rasmi cha /cron.sh dhidi ya volumu zilezile. Iambie Nextcloud itegemee huduma hiyo:

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

Kila amri ya occ hufuata umbo hilo: docker compose exec -u www-data app php occ <command>. Inafaa kuweka alias.

Hifadhi rudufu: vitu vitatu, au hakuna kabisa

Hifadhi rudufu ya mfumo wa faili pekee hairejeshi mfumo uliovunjika. Saraka ya data huhifadhi baiti; Postgres huhifadhi cache ya faili, shares, watumiaji, na hali ya programu; config.php huhifadhi vitambulisho vya database, kitambulisho cha instance (instance ID) na chumvi ya nenosiri (password salt). Rejesha faili bila database na Nextcloud haitaweza kuziona. Rejesha database bila config.php na haitaweza kufungua database hiyo. Rejesha database ya zamani dhidi ya saraka ya data mpya na utapata shares zinazoelekeza kwenye faili zilizohamishwa.

Hifadhi vitu vyote vitatu, kutoka kwa instance iliyosimamishwa (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/

Maintenance mode ndiyo inayofanya dump na nakala ya faili zilingane. Iruke na hatimaye utapata database inayorejelea faili ambayo rsync ilikuwa bado haijaifikia. Kumbuka kuwa script hii huhifadhi dumps za database zenye timestamp lakini ni mirror moja tu inayozunguka ya saraka ya data, rsync --delete huifuta na kuandika upya kila inapoendeshwa, kwa hivyo dump mpya zaidi pekee ndiyo inayooana na nakala ya faili.

Kisha iondoe kwenye seva hiyo. Hifadhi rudufu inayokaa kwenye VPS ileile inayohifadhiwa ni nakala tu, si hifadhi rudufu. restic dhidi ya object storage au host ya pili ndiyo jibu la kawaida, na deduplication yake hushughulikia saraka ya data vizuri zaidi kuliko tarball ya kila usiku. Usanidi kamili, kuanzia kuanzisha repository hadi timer ya kila usiku na mazoezi ya kurejesha, uko kwenye hifadhi rudufu za VPS nje ya seva kwa kutumia restic.

Kurejesha siyo kinyume chake tu. Stack iliyoanzishwa upya huendesha kisakinishi na kuandika config.php mpya kabisa, kitambulisho kipya cha instance na chumvi ya nenosiri, na kuingiza dump juu ya utambulisho huo mpya huacha sessions na share tokens zilizovunjika. Rudisha utambulisho wa zamani kwanza, kwa utaratibu huu:

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 hupatanisha cache ya faili na kile kilichopo kwenye diski. Fanya mazoezi haya mara moja, kwenye VPS ya ziada, kabla hujayahitaji. Mgawanyo uleule kati ya baiti kwenye diski na metadata kwenye Postgres huongoza kila programu nyingine ya aina hii, ndiyo maana hifadhi rudufu ya Immich inayokamata maktaba lakini si database hurejesha timeline tupu.

Uboreshaji: toleo moja kuu kwa wakati mmoja

Nextcloud inaruhusu kuboresha toleo moja kuu kwa wakati mmoja. Kuruka kutoka 29 kwenda 31 hakufanikiwi kwa usalama, kunasababisha Exception: Updates between multiple major versions and downgrades are unsupported. na kukuacha katika hali ya maintenance mode.

Uboreshaji wa Docker ni: tengeneza backup, badilisha tag kutoka 31 kwenda 32 katika huduma zote mbili za app na cron, kisha tumia docker compose pull && docker compose up -d, na hatimaye docker compose logs -f app. Entrypoint ya image hutambua msimbo mpya dhidi ya data iliyopo na kujiendeshea occ upgrade yenyewe. Usiikatize. Wakati logi zinapokaa kimya, endesha docker compose exec -u www-data app php occ status na uhakiki versionstring na kwamba programu zimerudi na kuwezeshwa.

Sheria mbili zitakazokuokoa: ongeza toleo moja kuu, hakiki, kisha ongeza linalofuata. Na usibadilishe kamwe tag kwenye huduma ya app bila kubadilisha cron ili zilingane; matoleo mawili tofauti ya Nextcloud dhidi ya database moja ni njia ya kuharibu data.

Hitilafu utakazokutana nazo

"Your data directory is readable by other users. Please change the permissions to 0770." Saraka iliyowekwa kupitia bind-mount ina ruhusa za kusoma kwa kundi au watumiaji wengine. sudo chmod 0770 /srv/nextcloud/data na 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 inaelekeza mahali ambapo Nextcloud haijawahi kuanzishwa, kuna kosa la tahajia kwenye njia ya faili, au saraka mpya tupu imewekwa badala ya ile inayofanya kazi. Hakikisha njia ya faili kwenye host inalingana na mstari wa volume.

"Access through untrusted domain." Jina la mwenyeji (hostname) katika ombi halipo kwenye trusted_domains. NEXTCLOUD_TRUSTED_DOMAINS inatumika tu wakati wa usakinishaji wa kwanza; baada ya hapo, iweke iwe hai: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, pamoja na connect() failed (111: Connection refused) while connecting to upstream katika /var/log/nginx/error.log. nginx haikufikia chochote kwenye 127.0.0.1:8080. Aidha kontena bado linaanzishwa (kagua docker compose logs app), limejifunga (docker compose ps), au mstari wa publish haulingani na port ya proxy_pass. Thibitisha kwa kutumia ss -ltnp | grep 8080.

Mzunguko wa kuelekezwa upya (redirect loop), au maonyo ya "insecure" katika muhtasari wa admin. OVERWRITEPROTOCOL: https haipo, au TRUSTED_PROXIES haina subnet ya Docker gateway. Tazama sehemu ya proxy hapo juu.

LockedException: "files/..." is locked. Pamoja na REDIS_HOST kuwekwa, image inasanidi Redis kama backend ya kufunga (locking backend) na kufuli zilizopitwa na wakati ni nadra. Bila hiyo, kufuli hukaa kwenye jedwali la database oc_file_locks na ombi linalokatishwa katikati ya uandishi huacha safu (rows) nyuma. Thibitisha kama Redis inatumika kweli, occ config:system:get memcache.locking inapaswa kurejesha darasa la Redis, kabla ya kufuta safu za kufuli kwa mkono.

"The PHP memory limit is below the recommended value of 512MB." Ongeza PHP_MEMORY_LIMIT na uunde upya kontena. Kumbuka athari ya hatua hiyo kwa kiwango cha juu cha matumizi ya kumbukumbu.

Mambo yanayoharibika kwa ongezeko la matumizi

Kikwazo cha kwanza ni saraka ya data kuzidi uwezo wa volume. Kuongeza ukubwa wa volume kwenye VPS kunahusisha kufanya resize na kisha kukuza filesystem; ni rahisi zaidi kufanya hivyo kwa ratiba kuliko kusubiri diski ijae kwa 100%. Weka tahadhari ya matumizi ya diski sasa, usisubiri baadaye.

Kikwazo cha pili ni oc_filecache. Orodha za faili na skani za usawazishaji (sync) hupungua kasi kadiri idadi ya safu (rows) inavyoongezeka. Suluhisho ni kazi ya database: weka Postgres kwenye hifadhi ya haraka, iruhusu itumie kumbukumbu ya kutosha ya shared memory, na ufute takataka pamoja na matoleo ya zamani (versions) kwa kutumia mipangilio ya retention badala ya kuyaacha yakusanyike milele.

Kikwazo cha tatu ni utengenezaji wa preview kushindana na kazi nyingine. Kwenye seva ndogo, punguza watoa huduma wa preview na usiwahi kuendesha occ preview:generate-all wakati wa saa za kazi. Ikiwa picha za simu ndizo nyingi unazohifadhi, kazi hiyo ya thumbnail inafaa kufanyika kwenye seva maalum ya picha, na ulinganisho wa PhotoPrism na Immich kuhusu RAM, apps za simu na amri za backup unaelezea gharama za kila moja ikilinganishwa na Nextcloud box.

Zaidi ya hapo, jibu la kweli ni kwamba huduma za ziada zinahitaji mashine yao wenyewe. Collabora na full-text search ni huduma tofauti zinazokaa kwenye kumbukumbu na zina mahitaji yao ya RAM. Kuziweka kwenye kisanduku kimoja kinachohifadhi nakala pekee ya faili zako kunapanua wigo wa hatari ya kufeli bila faida yoyote. Ikiwa kuhariri nyaraka kwenye kivinjari ndiyo huduma ya ziada unayotaka, viwango vya chini vya RAM na mipaka ya muunganisho inayotofautisha OnlyOffice na Collabora ndivyo vitakavyoamua ni ipi VPS ya 2 hadi 4 GB inaweza kubeba. Hamisha hifadhi ya faili kwenye S3-compatible primary storage wakati volume inapokosa kufaa, na kumbuka kuwa hii hufanya backup kuwa ngumu zaidi, si rahisi: database bado inashikilia metadata, na lazima itolewe (dumped) sambamba na bucket.

Instance ikishaanza kuhudumia watumiaji halisi, weka Uptime Kuma mbele yake ili upate taarifa za downtime kabla ya sync clients hazijagundua. Private cloud inafanya kazi vizuri na seva yako ya barua pepe, na ikiwa hutaki kuunganisha huduma kwa mikono, Cloudron, CasaOS na Coolify inalinganisha majukwaa yanayokufanyia kazi hiyo. Ikiwa injini ya utafutaji (search engine) ya kujihudumia ndiyo inayofuata kwenye orodha hiyo, tarajia matatizo ya aina tofauti na yale ya hapo juu: makosa ya 429 ya SearXNG hutokana na rate limiter yake yenyewe au injini za juu (upstream engines) kuzuia IP ya VPS yako, na log pekee ndiyo itakuambia ni lipi kati ya hayo.

FAQ

Je, ninaweza kuendesha Nextcloud kwenye SQLite badala ya Postgres?

Unaweza, na image rasmi itakuruhusu, lakini mteja mmoja wa desktop sync anayetoa maombi mengi kwa wakati mmoja atasababisha SQLSTATE[HY000]: General error: 5 database is locked na makosa ya HTTP 500. SQLite hufunga database nzima wakati wa kuandika, na Nextcloud huandika mara kwa mara, kama vile file locks, safu za shughuli, na hali ya kazi. Anza na Postgres au MariaDB; occ db:convert-type ipo lakini ni uhamiaji mrefu na mgumu wa data iliyo hai.

Nextcloud VPS inahitaji RAM kiasi gani?

Pima kulingana na idadi ya maombi ya wakati mmoja, si idadi ya watumiaji. Kumbukumbu inayotumiwa kwa kawaida ni takriban idadi ya maombi ya wakati mmoja ikizidishwa na PHP_MEMORY_LIMIT, pamoja na Postgres shared buffers na backend moja kwa kila muunganisho, na kile ambacho preview generation inaweza kuhitaji kwa muda mfupi. Seva ya 2 GB inaweza kuendesha instance ndogo ya nyumbani ikiwa utapunguza previews na kuongeza swap; ukiongeza Collabora au full-text search, utahitaji kuongeza rasilimali kwa ajili ya huduma hizo za ziada.

Kwa nini uploads kubwa hushindwa nyuma ya nginx reverse proxy?

Mipangilio miwili kwenye proxy mara nyingi ndiyo sababu: client_max_body_size ikiachwa kwenye thamani ya msingi ya 1 MB itakata ombi, na thamani ndogo za proxy_read_timeout / proxy_send_timeout zitakatisha uhamishaji mrefu katikati. Weka thamani hizi kwa ukarimu, badilisha proxy_request_buffering off iwe stream badala ya spool, na uongeze PHP_UPLOAD_LIMIT kwenye app container ili ilingane.

Kwa nini Nextcloud huingia kwenye redirect loop au kutoa onyo kuhusu reverse proxy?

Container haioni nginx kwenye 127.0.0.1, inaona Docker bridge gateway, mahali fulani ndani ya 172.x. Anwani hiyo inapokosekana kwenye TRUSTED_PROXIES, header ya X-Forwarded-Proto: https hupuuzwa, Nextcloud hutoa URLs za http://, na proxy huzirudisha nyuma. Weka TRUSTED_PROXIES kwenye subnet halisi ya bridge na uweke OVERWRITEPROTOCOL: https.

Je, ninaweza kupandisha Nextcloud kutoka 29 moja kwa moja hadi 31?

Hapana. Nextcloud inasaidia toleo moja kuu kwa kila upgrade, na kuruka toleo kutasababisha Updates between multiple major versions and downgrades are unsupported., na kuacha instance katika hali ya maintenance mode. Fanya backup, badilisha tag kwenda toleo moja kuu linalofuata kwenye huduma zote mbili za app na cron, docker compose pull && docker compose up -d, thibitisha na occ status, kisha rudia mchakato.