SSD Nodes Learn
Mwongozo Matt ConnorNa Matt Connor · Imeboreshwa 2026-07-25

Jinsi ya kuendesha Nextcloud kwenye VPS kwa Docker

Mwongozo wa kusakinisha Nextcloud kwenye VPS kwa kutumia Docker Compose, Postgres, Redis na nginx kwa TLS. Unajifunza hatua za hifadhi rudufu na upya kwa ajili ya kurejesha data yako.

Unachojenga kimsingi

Mwongozo huu huendesha Nextcloud kwenye VPS kwa kutumia Docker Compose, huweka Let's Encrypt TLS mbele yake, na huandaa hifadhi rudufu inayoweza kurejeshwa kwa kweli. Vyombo vinne na proksi moja: picha rasmi ya nextcloud inayosikiliza kwenye loopback, Postgres inayoshikilia kila kipande cha metadata ya faili, Redis inayoshikilia file locks, nakala ya pili ya picha ya Nextcloud inayoendesha tu cron loop, na nginx kwenye mwenyeji inayomaliza TLS mbele ya vyote hivyo. Usakinishaji wenyewe unachukua dakika ishirini, na sio sehemu muhimu. Maamuzi mawili yanayofanywa katika saa ya kwanza huamua kama bado utakuwa na faili zako baada ya mwaka mmoja: hifadhidata halali badala ya SQLite, na hifadhi rudufu inayokamata saraka ya data, hifadhidata na config.php kama seti moja thabiti.

Hii inadhani Ubuntu 24.04 LTS au Debian 13, Docker Engine ikiwa na plugin ya Compose v2 iliyosakinishwa kutoka hazina ya Docker yenyewe, na rekodi ya DNS A (pamoja na AAAA kama una IPv6) tayari inayoelekeza cloud.example.com kwenye VPS. Vyote vinahitaji seva unayoizidhibiti — hakuna njia ya kufanya ukatishaji wa TLS na kutoa dump ya hifadhidata kwenye SaaS ya mtu mwingine.

Ukubwa: kile ambacho kinatumia kumbukumbu halisi

Matumizi ya kumbukumbu ya Nextcloud huathiriwa na vitu vitatu, na hakimoja kati yake ni "Nextcloud" yenyewe.

Wafanyakazi wa PHP. Picha ya -apache inahudumia kila ombi la wakati mmoja kupitia mchakato wa mfanyakazi ambao unashikilia kigeuzi cha PHP. Kila mfanyakazi anaweza kukua hadi PHP_MEMORY_LIMIT kabla ya PHP haujaui ombi. Kumbukumbu yako ya hali mbaya zaidi ya makazi ni takriban maombi ya wakati mmoja × kikomo cha kumbukumbu, na mteja wa usawazishaji wa eneo-kazi hufungua muunganisho kadhaa sambamba kwa kila mtumiaji. Uwezo wa wakati mmoja, sio idadi ya watumiaji, ndio unaoweka kikomo.

Hifadhidata. Postgres hugawa seva ya nyuma kwa kila muunganisho na kushikilia bufferi za pamoja makazini. Seti yake ya kazi inabadilika kulingana na idadi ya faili, sio idadi ya baiti: oc_filecache hubeba safu moja kwa kila faili kwa kila mtumiaji. Faili elfu mia ndogo ni hifadhidata nzito kuliko faili mia kubwa.

Uzalishaji wa hakikisho. Kuzalisha kijipicha hukitumia picha ya chanzo katika kumbukumbu kwa azimio kamili. Hakikisho za video huitumia ffmpeg. Kuendesha occ preview:generate-all hufanya ile mlipuko mara kwa mara, mfululizo, na ndiyo njia ya kawaida zaidi ya kusukuma VPS ndogo kwenye kiuaji cha OOM.

Redis ni nafuu kulinganisha. Kila kitu unachokiongeza baadaye — Collabora, utafutaji wa maandishi kamili, kichunguzi cha virusi — ni huduma tofauti ya makazi yenye alama yake ya kumbukumbu, na kinapaswa kuwa katika mpango wako wa ukubwa kabla ya kukiwezesha.

Vidhibiti, kama unakosa RAM: punguza PHP_MEMORY_LIMIT, weka kikomo preview_max_x / preview_max_y / preview_max_filesize_image, punguza enabledPreviewProviders kwa fomati unazozitazama kweli, na weka trashbin_retention_obligation na versions_retention_obligation ili saraka ya data isikue kimyakimya hadi mara kadhaa za ukubwa wa faili zako. Ongeza faili la swap. Swap ni polepole, na mauaji ya OOM katikati ya uboreshaji ni mbaya zaidi.

Kwa nini SQLite hushindwa

Nextcloud huja na usaidizi wa SQLite na picha rasmi itatumia bila shida. Usitumie. SQLite huandika kwa mlolongo kwa kutumia kifulio cha kiwango cha hifadhidata yote: mwandishi mmoja kwa wakati mmoja, kwa faili nzima. Nextcloud huandika kila wakati — kifulio cha faili, safu za shughuli, ingizo la akiba, hali ya kazi — na mteja mmoja wa kompyuta anayelandanisha mti wa saraka hutuma maombi mengi sambamba. Kwa hali hiyo unapata SQLSTATE[HY000]: General error: 5 database is locked na HTTP 500, na hitilafu inaonekana hasa wakati mfumo unapoanza kuwa na manufaa.

Kubadilisha baadaye kunawezekana kwa kutumia occ db:convert-type, lakini ni uhamishaji mrefu, unaorudisha wote au hakuna, kwenye seti ya data inayotumika. Anza na Postgres au MariaDB.

Faili la Compose

Weka hili katika /srv/nextcloud/compose.yaml, na siri katika faili la jirani la .env lenye modi 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 tag kuu na kagua tag inayotumika sasa kwenye Docker Hub kabla huja nakili 31 kama ilivyo. latest itakusogeza kupitia kikomo kuu katika docker compose pull fulani ya baadaye, na Nextcloud haikubali hilo.

Saraka ya data ni bind mount, sio named volume, kusudi: nji unayoweza kuelekeza zana ya backup moja kwa moja ni muhimu zaidi kuliko mpangilio safi. Unda kwa UID ya www-data ya image na ruhusa Nextcloud inazihitaji:

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

Angalia kuchapisha mlango: 127.0.0.1:8080:80. Docker huchapisha milango kwa kuandika kanuni za DNAT zinazotathminiwa kabla ya mnyororo wa INPUT wa ufw haujaona paketi — 8080:80 pekee kiwekacho Nextcloud isiyo fungwa kwenye mtandao wa umma bila kujali ufw inasema nini. Kufunga kwenye loopback kinaificha kutoka kwenye kiolesura cha umma. Kisha firewall inabidi iruhusu wakala tu — na kama hutaki kuacha SSH wazi kwa mtandao wa umma mzima, kufikia VPS kupitia VPN ya WireGuard inayojidhibiti inakuruhusu kuondoa mlango 22 kutoka kwenye kanuni za umma kabisa:

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

Iinue kwa docker compose up -d, kisha fuatilia docker compose logs -f app. Uwashi wa kwanza unakopi mti mzima wa programu kwenye volume na kuendesza kifaa cha usakinishaji; kontena hairudishi jibu lolote hadi hilo likamilike.

TLS na proksi ya kinyume

Sakinisha nginx na certbot kutoka kwa usambazaji, tengeneza kizuizi cha seva cha kawaida cha port-80 chenye server_name sahihi, kisha ruhusu certbot kiandae upya. Mbinu za changamoto ya HTTP-01, kipima muda wa upya, na hali za kutofaulu zimeelezwa kikamilifu katika kutoa 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 uelekeo wa :80:443, na husakinisha kipima muda cha systemd kinachosasisha cheti cha siku 90. Thibitisha kwamba kinapo kwa kutumia systemctl list-timers | grep certbot — kipima muda cha upya ambacho hakijawashwahi ni mlinganisho wa siku 90.

Kizuizi cha proksi 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 toleo jipya zaidi, ongeza http2 on;. Ubuntu 24.04 inakuja na toleo la zamani ambapo sawa nalo ni listen 443 ssl http2;. nginx -t itakuambia ni kipi kati ya hicho toleo lako linakubali.

client_max_body_size na muda mrefu wa kusoma ndivyo vinavyozuia kupakia kwa faili kubwa kusimama katikati. proxy_request_buffering off hupitisha faili lililopakiwa moja kwa moja badala ya kukiweka kwanza kwenye diski ya proksi.

nginx kwenye mwenyeji ndilo jambo jepesi zaidi linalofanya kazi kwa programu moja. Ikiwa Nextcloud itashiriki VPS na kontena nyingine, kuendesha Traefik kama proksi ya kinyume ya Docker Compose kwa programu nyingi huhamisha uelekeaji na utoaji wa vyeti kuwa kwenye lebo za kontena, na masuala yale yale ya client_max_body_size na muda wa kusubiri hujitokeza tena hapo kama mipangilio ya middleware na transport.

trusted_proxies na overwriteprotocol

Hapa ndipo wapi ambapo mifumo mingi ya Nextcloud inayojitegemea hukosa, na dalili zinaonekana hazihusiani na sababu.

X-Forwarded-Proto: https huheshimiwa tu wakati ombi linapotoka kutoka anwani iliyoorodheshwa katika trusted_proxies. Ikiwa haliheshimiwi, Nextcloud hudhani kuwa ombi ni la kawaida la HTTP na hutoa URL za http://; proxy inazielekeza upya kwenye HTTPS; kivinjari kinafuata; Nextcloud hutoa http:// tena. Hii ndio mzunguko wa uelekeo upya. OVERWRITEPROTOCOL: https hubandika mpangilio bila kujali muktadha.

Mtego katika TRUSTED_PROXIES ni kwamba anwani ambayo Nextcloud inaiona siyo 127.0.0.1. nginx inaendeshwa kwenye mwenyeji na inaunganishwa kwenye mlango uliochapishwa, hivyo kontena inaona lango la daraja la Docker — kitu kilicho katika 172.x. Tafuta mtandao halisi:

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

Weka hicho CIDR (au 172.16.0.0/12 inayofunika) katika TRUSTED_PROXIES. Ukiweka kipana sana, mteja yeyote anaweza kudanganya X-Forwarded-For; ukiweka kosa, kila kuingia kinaonekana kuhusiana na anwani ya lango, ulinzi dhidi ya mashambulizi ya nguvu unazuia mfumo wako mzima mara moja, na muhtasari wa msimamizi unaonyesha "Usanidi wa kichwa cha proxy ya kurejesha si sahihi, au unafikia Nextcloud kutoka proxy inayoaminika."

OVERWRITECLIURL ni muhimu kwa kontena ya cron, ambayo haina ombi la kuingia la kupata jina la mwenyeji. Bila hilo, kazi za usuli zinazalisha viungo vya localhost na arifa za barua pepe zinatuma URL zisizoweza kutumika.

Kazi za usuli: cron, sio AJAX

Kitekelezi chaguo-msingi cha kazi cha Nextcloud ni AJAX: kazi hutekelezwa kama matokeo ya pembeni ya mtu kufungua ukurasa. Hakuna anayevinjari saa 04:00, hivyo muda wa kuisha wa takataka, usafishaji wa toleo, hakikisho, na majaribio ya shirikiani hukwama. Dalili ya kwanza ni saraka ya data inayoendelea kukua bila kusimama. Huduma ya cron hapo juu hutekeleza mzunguko rasmi wa /cron.sh kwenye vilima sawa. Mwambie Nextcloud kuitarajia:

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

Kila amri ya occ inafuata muundo huo: docker compose exec -u www-data app php occ <command>. Inafaa kuwekwa kiakisi.

Hifadhi nakala: vitu vitatu, au hakuna

Hifadhi nakala ya mfumo wa faili pekee hurudisha mfumo uliovurugika. Saraka ya data inashikilia baiti; Postgres inashikilia akiba ya faili, mashiriki, watumiaji, na hali ya programu; config.php inashikilia vitambulisho vya hifadhidata, kitambulisho cha mfumo na chumvi ya nywila. Rudisha faili bila hifadhidata na Nextcloud haziwezi kuziona. Rudisha hifadhidata bila config.php na haiwezi kufungua hifadhidata. Rudisha hifadhidata ya zamani dhidi ya saraka ya data mpya zaidi na utapata mashiriki yanayotaja faili zilizohamishwa.

Hifadhi nakala vitu vyote vitatu, kutoka kwa mfumo uliositishwa:

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

Hali ya matengenezo ndiyo inayofanya nakala ya hifadhidata na nakala ya faili zilingane. Ruka hali hii na hatimaye utachukua hifadhidata inayotaja faili ambayo rsync bado haijafikia. Kumbuka kuwa hati inahifadhi nakala za hifadhidata zenye alama za muda lakini kioo kimoja tu kinachozunguka cha saraka ya data — rsync --delete kinaifuta kila uendeshaji — hivyo nakala mpya zaidi tu ndiyo inayoambatana na nakala ya faili.

Kisha iondoke kutoka kwenye seva. Nakala inayoishi kwenye VPS ile ile na kitu kinachohifadhiwa ni nakala tu, sio hifadhi nakala. restic dhidi ya hifadhi ya vitu au mwenyeji wa pili ndiyo jibu la kawaida, na uondoaji wa nakala rudufu unashughulikia saraka ya data vizuri zaidi kuliko faili ya tar ya usiku. Usanidi kamili, kutoka kuanzisha hazina hadi kipima muda cha usiku na mazoezi ya kurudisha, uko katika hifadhi nakala za VPS nje ya seva kwa restic.

Kurudisha sio kinyume cha moja kwa moja. Mfumo ulioanza upya hufanya usakinishaji na kuandika config.php mpya kabisa — kitambulisho kipya cha mfumo na chumvi ya nywila — na kuingiza nakala juu ya utambulisho huo mpya husababisha vikao na alama za ushiriki zilizovurugika. Rudisha utambulisho wa zamani kwanza, kwa mpangilio 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 inalinganisha akiba ya faili na kile kilichopo kwenye diski kwa halisi. Fanya mazoezi haya mara moja, kwenye VPS ya ziada, kabla ya kuhitaji.

Uboreshaji: toleo kuu moja kwa wakati mmoja

Nextcloud inaruhusu kuboresha toleo kuu moja kwa wakati mmoja tu. Kuruka moja kwa moja kutoka toleo 29 hadi 31 haifeli kwa heshima — inashindwa kwa Exception: Updates between multiple major versions and downgrades are unsupported. na inakuacha katika hali ya matengenezo.

Mchakato wa kuboresha Docker ni: fanya hifadhi nakala, hariri lebo kutoka 31 hadi 32 katika huduma zote mbili za app na cron, kisha docker compose pull && docker compose up -d, kisha docker compose logs -f app. Kituo cha kuanzia cha image kinatambua msimbo mpya dhidi ya data iliyopo na kinaendesha occ upgrade chenyewe. Usikatishe mchakato huo. Logi zikakwisha, endesha docker compose exec -u www-data app php occ status na kagua versionstring pamoja na kuangalia kwamba programu-tumizi zimerudi kuwa zimewashwa.

Kanuni mbili zinazokuokoa: panda toleo kuu moja, thibitisha, kisha panda linalofuatia. Na usihariri kamwe lebo kwenye huduma ya app bila kuhariri cron ili ziambatane — toleo mbili tofauti za Nextcloud dhidi ya hifadhidata moja ni njia ya kuharibu data.

Makosa unayoweza kuona kwa kweli

"Your data directory is readable by other users. Please change the permissions to 0770." Saraka iliyopachikwa kwa bind ina biti za usomaji kwa kikundi au watumiaji wote. 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 inaelekelea mahali Nextcloud haijawahi kuanzisha — makosa katika andishi la njia, au saraka tupu mpya iliyobadilishwa chini ya mfumo unaoendelea. Hakikisha njia ya mwenyeji inalingana na mstari wa volume.

"Access through untrusted domain." Jina la mwenyeji katika ombi halimo kwenye trusted_domains. NEXTCLOUD_TRUSTED_DOMAINS inatumika tu wakati wa usakinishaji wa kwanza; baada ya hapo weka moja kwa moja: 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 inaanzishwa (angalia docker compose logs app), imejitoa (docker compose ps), au mstari wa publish haulingani na port ya proxy_pass. Thibitisha kwa ss -ltnp | grep 8080.

Mzunguko wa uelekezaji upya, au onyo la "insecure" katika muhtasari wa msimamizi. OVERWRITEPROTOCOL: https haipo, au TRUSTED_PROXIES haionyeshi mtandao mdogo wa lango la Docker. Angalia sehemu ya proxy hapo juu.

LockedException: "files/..." is locked. Ukiwa na REDIS_HOST imewekwa, picha husanidi Redis kama backend ya kufunga na kufunga za zamani ni nadra. Bila hilo, kufunga zimo kwenye jedwali la database oc_file_locks na ombi lililovunjwa katikati ya kuandika husafirisha safu zisizohitajika. Thibitisha Redis inatumika kwa kweli — occ config:system:get memcache.locking inapaswa kurudisha darasa la Redis — kabla ya kusafisha safu za kufunga kwa mkono.

"The PHP memory limit is below the recommended value of 512MB." Ongeza PHP_MEMORY_LIMIT na uunde tena kontena. Kumbuka athari ya jambo hilo kwenye kikomo chako cha juu kabisa.

Nini huisha ukikua

Kikwazo cha kwanza ni saraka ya data kuzidi ukubwa wa volume. Kuongeza ukubwa wa volume kwenye VPS ni kubadilisha ukubwa pamoja na kupanua mfumo wa faili. Hii inaumiza kidogo ikiwa imepangwa mapema kuliko wakati volume imejaa 100% — weka arifa za matumizi ya diski sasa, si baadaye.

Kikwazo cha pili ni oc_filecache. Orodha za faili na uchunguzi wa usawazishaji hupunguza mwendo kadiri idadi ya safu inavyozidi. Suluhisho ni kazi ya hifadhidata: weka Postgres kwenye hifadhi haraka, iruhusu kutumia kumbukumbu shirikishi ya kutosha, na futa takataka na toleo kwa mipangilio ya kudumu badala ya kuziruhusu zijilimbikize milele.

Kikwazo cha tatu ni uzalishaji wa hakikisho kushindana na shughuli zote zilizopo. Kwenye seva ndogo, weka watoa hakikisho wachache na usiendeshe occ preview:generate-all wakati wa masaa ya kazi.

Baada ya hayo, jibu la kweli ni kwamba huduma za ziada zinahitaji seva zao. Collabora na utafutaji wa maandishi kamili ni huduma za kudumu zenye kujitegemea zenye majedwali ya kumbukumbu yao. Kuziweka kwenye seva inayoshikilia nakala yako pekee ya faili huongeza eneo la hitilafu bila faida yoyote. Hamisha hifadhi ya faili kwenda hifadhi kuu inayolingana na S3 wakati volume haifai tena — na elewa kuwa hii huifanya hifadhi rudufu kuwa ngumu zaidi, si rahisi: hifadhidata bado inashikilia metadata, na lazima idondolewe kwa pamoja na bucket.

Mara mfumo unapoanza kutumikia watumiaji halisi, weka Uptime Kuma mbele yake ili ujue kuhusu muda wa kutumia kabla ya wateja wa usawazishaji. Wingu binafsi hulingana vizuri na seva yako ya barua pepe, na kama hutaki kuunganisha huduma kwa mikono, Cloudron, CasaOS na Coolify inalinganisha majukwaa ambayo hufanya hivyo kwa niaba yako.

FAQ

Ninaweza kuendesha Nextcloud kwenye SQLite badala ya Postgres?

Unaweza, na picha rasmi itakuruhusu, lakini mteja mmoja wa usawazishaji wa desktop anayotuma maombi sambamba utakutana na SQLSTATE[HY000]: General error: 5 database is locked na HTTP 500. SQLite huchukua kufunga kuandika kwa hifadhidata nzima, na Nextcloud huandika kila wakati — kufunga faili, safu za shughuli, hali ya kazi. Anza na Postgres au MariaDB; occ db:convert-type ipo lakini ni uhamishaji mrefu, wa yote au hakuna, kwenye data hai.

Kiasi gani cha RAM kinachohitajika kwa VPS ya Nextcloud kwa halisi?

Pima kwa kasi ya sambamba, si idadi ya watumiaji. Kumbukumbu iliyopo katika hali mbaya zaidi ni takriban idadi ya maombi sambamba kuzidishwa na PHP_MEMORY_LIMIT, pamoja na buffers zilizoshirikishwa za Postgres na backend moja kwa kila muunganisho, pamoja naile inayotokea wakati wa kutengeneza hakikisho. Seva ya 2 GB inaendesha mfano mdogo wa nyumbani ikiwa utaweka kikomo kwa hakikisho na kuongeza swap; ongeza Collabora au utafutaji wa maandishi kamili na utakuwa unapima seti ya pili ya huduma zinazokaa kwenye kumbukumbu.

Kwa nini kupakia kubwa kunashindwa nyuma ya wakala wa kurejea wa nginx?

Mipangilio miwili kwenye wakala kwa kawaida hufafanua hili: client_max_body_size iliachwa kwa chaguo-msingi ya 1 MB hukata maombi, na thamani fupi za proxy_read_timeout / proxy_send_timeout huzuia uhamishaji mrefu katikati. Weka zote mbili kwa ukarimu, geuza proxy_request_buffering off kuwa mtiririko badala ya spool, na ongeza PHP_UPLOAD_LIMIT kwenye kontena la programu ili zilingane.

Kwa nini Nextcloud inarejea kwenye mzunguko au kuonya kuhusu wakala wa kurejea?

Kontena haioni nginx kwenye 127.0.0.1 — inaona lango la daraja la Docker, mahali popote ndani ya 172.x. Anwani hiyo inapokosekana kwenye TRUSTED_PROXIES, kichwa cha X-Forwarded-Proto: https hakitazingatiwa, Nextcloud hutoa URL za http://, na wakala unazirudisha. Weka TRUSTED_PROXIES kuwa mtandao halisi wa daraja na ushikilie OVERWRITEPROTOCOL: https.

Ninaweza kuboresha Nextcloud kutoka 29 moja kwa moja hadi 31?

Hapana. Nextcloud haitoa msaada kwa toleo kuu moja kwa kila uboreshaji, na kuruka huishia na Updates between multiple major versions and downgrades are unsupported., na kuacha mfano katika hali ya matengenezo. Cheleza nakala, ongeza tag moja kuu kwa huduma zote mbili za app na cron, docker compose pull && docker compose up -d, thibitisha na occ status, kisha rudia.