Instalacja Nextclouda na własnym serwerze

Nextcloud rozpakowuje się w kilka sekund. Czas zjada dopiero to, co przychodzi potem: strona przeglądu w sekcji Ustawienia administracyjne przy świeżej instalacji praktycznie zawsze pokazuje listę żółtych i czerwonych ostrzeżeń, wysyłanie plików urywa się przy 2 MB, a otwarcie strony po adresie IP kończy się komunikatem „You are accessing the site from an untrusted domain.”. Ten artykuł przechodzi całą drogę do końca i zatrzymuje się dokładnie w tych miejscach, w których większość poradników się urywa.

Zdecyduj wcześniej: wersja PHP, baza danych, miejsce na dane

Nextcloud jest znacznie mocniej związany z wersją PHP niż większość innego oprogramowania serwerowego. Aktualne serie 33 i 34 wymagają co najmniej PHP 8.2, seria 32 działa jeszcze od PHP 8.1. To dystrybucja decyduje więc o tym, czy wystarczą ci pakiety z jej własnych repozytoriów:

Debian 11 to przypadek najbardziej podstępny i mimo to lubi się ujawnić dopiero późno, bo instalacja pakietów przebiega bez jednego błędu. Metapakiet php ciągnie tam PHP 7.4, a aktualna wersja Nextclouda przerywa z tym przy pierwszym otwarciu w przeglądarce błędem HTTP 500 i komunikatem „This version of Nextcloud requires at least PHP 8.2”. Debian 11 i tak wypadł już z regularnego wsparcia, więc jako podstawa nowej instalacji się nie nadaje. Jeśli naprawdę musisz go użyć, podepnij wcześniej repozytorium Sury i instaluj wyraźnie wersjonowane pakiety, czyli php8.2-fpm, php8.2-cli, php8.2-mysql i tak dalej, zamiast metapakietów bez numeru wersji.

Na Ubuntu 22.04 równie nieuchronnie uderzysz w ścianę, gdy tylko wgrasz aktualną wersję Nextclouda. Albo świadomie zostajesz przy serii 32, albo bierzesz PHP ze znanego PPA:

sudo apt-get install -y software-properties-common
sudo add-apt-repository -y ppa:ondrej/php
sudo apt-get update
sudo apt-get install -y php8.3-fpm php8.3-cli php8.3-mysql

Dwie kolejne rzeczy ustala się na samym początku, a później zmienia tylko z dużym trudem. Po pierwsze: Debian zasadniczo nie dostarcza pakietu mysql-server, tam z góry wybrana jest MariaDB. Po drugie: katalog danych nie należy do /var/www/nextcloud/data, tylko poza katalog główny serwera WWW, na przykład do /var/nextcloud-data. Domyślna ścieżka jest groźna wyłącznie z jednego powodu: przy zepsutej konfiguracji serwera WWW wyda ona wszystkie pliki użytkowników. Nextcloud ostrzega w takim wypadku komunikatem „Your data directory and files are probably accessible from the internet”, ale dopiero wtedy, gdy błąd już istnieje.

Konfiguracja serwera WWW, PHP i bazy danych

Bierzemy nginx z PHP-FPM. Jeśli wolisz Apache z mod_php, drogę opisuje artykuł Apache, PHP i MySQL na Debianie, a wątki dotyczące PHP z dalszej części obowiązują bez zmian. Podstawową instalację serwera nginx znajdziesz w artykule instalacja nginx.

sudo apt-get update
sudo apt-get install -y nginx mariadb-server
sudo apt-get install -y php-fpm php-cli php-mysql php-gd php-curl php-mbstring php-intl php-gmp php-bcmath php-xml php-zip php-imagick php-apcu

Ta lista jest celowo dłuższa niż absolutne minimum. bcmath i gmp Nextcloud potrzebuje do logowania bez hasła, intl do poprawnego sortowania znaków diakrytycznych i specjalnych, imagick do miniatur, apcu do lokalnego cache. Jeśli brakuje któregoś z modułów obowiązkowych, kreator instalacji w ogóle cię dalej nie przepuści, a strona wypisze brakujące moduły z nazwy.

Sprawdź potem, co faktycznie zostało załadowane:

php -v
php -m

Druga częsta pułapka: istnieją dwie oddzielne konfiguracje PHP, jedna dla wiersza poleceń i jedna dla FPM. php --ini pokaże ci tę od wiersza poleceń, a konfiguracja serwera WWW leży w /etc/php/<version>/fpm/php.ini. Zmiany w niewłaściwym pliku nie dają żadnego efektu, a z doświadczenia to właśnie one zjadają najwięcej czasu.

Teraz baza danych. Najpierw zabezpiecz MariaDB, patrz zabezpieczanie MariaDB i MySQL, a potem:

sudo mariadb -e "CREATE DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"
sudo mariadb -e "CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'TutajDlugieHaslo';"
sudo mariadb -e "GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';"
sudo mariadb -e "FLUSH PRIVILEGES;"

Człon utf8mb4 w pierwszym poleceniu to nie szczegół. Jeśli założysz bazę z utf8, Nextcloud zgłosi później „MySQL is used as database but does not support 4-byte characters”, a przestawianie tego na działającej instancji jest wyraźnie bardziej nieprzyjemne niż poprawne CREATE DATABASE na starcie. Jeśli logowanie użytkownika bazy danych się nie powiedzie, pomoże artykuł usuwanie błędu Access denied for user.

Rozpakowanie i ustawienie uprawnień

sudo apt-get install -y wget unzip
wget https://download.nextcloud.com/server/releases/latest.zip
sudo unzip -q latest.zip -d /var/www
sudo mkdir -p /var/nextcloud-data
sudo chown -R www-data:www-data /var/www/nextcloud
sudo chown -R www-data:www-data /var/nextcloud-data
sudo chmod 750 /var/nextcloud-data

Uprawnienia to ten punkt, w którym najczęściej idzie się na skróty. Trzy typowe objawy i ich przyczyna:

• „Cannot write into config directory”: katalog /var/www/nextcloud/config nie należy do użytkownika serwera WWW. Na Debianie i Ubuntu jest nim www-data, natomiast na systemach AlmaLinux i Rocky apache albo nginx. Ślepo skopiowane chown www-data w rodzinie Red Hat trafia w próżnię.
• „Can't create or write into the data directory”: ścieżka nie istnieje, nie jest ścieżką bezwzględną, albo któryś z katalogów nadrzędnych jest dla www-data niedostępny do wejścia.
• „Your data directory is readable by other users”: uprawnienia są za szerokie. Wystarczy chmod 750 na katalogu danych.

Oprzyj się pokusie załatwienia problemu przez chmod -R 777. Nextcloud skwituje to dokładnie tym ostrzeżeniem, którego chciałeś się pozbyć, a przy okazji udostępnisz każdy plik do odczytu każdemu lokalnemu użytkownikowi.

Konfiguracja nginx

Nextcloud potrzebuje czegoś więcej niż standardowego bloku PHP, między innymi przepisywania adresów dla wykrywania usług pod /.well-known/ oraz blokad na katalogi wewnętrzne. Poniżej skrócona wersja oficjalnego wzorca, która działa w tej postaci:

upstream php-handler {
    server unix:/run/php/php8.3-fpm.sock;
}

server {
    listen 80;
    server_name cloud.example.com;
    root /var/www/nextcloud;

    client_max_body_size 10G;
    client_body_timeout 300s;
    fastcgi_buffers 64 4K;

    add_header Referrer-Policy "no-referrer" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Permitted-Cross-Domain-Policies "none" always;
    add_header X-Robots-Tag "noindex, nofollow" always;

    index index.php index.html /index.php$request_uri;

    location ^~ /.well-known {
        location = /.well-known/carddav { return 301 /remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /remote.php/dav/; }
        location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
        return 301 /index.php$request_uri;
    }

    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)              { return 404; }

    location ~ \.php(?:$|/) {
        rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+) /index.php$request_uri;
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_param front_controller_active true;
        fastcgi_pass php-handler;
        fastcgi_request_buffering off;
        fastcgi_max_temp_file_size 0;
    }

    location ~ \.(?:css|js|mjs|svg|gif|ico|jpg|png|webp|wasm|map|woff2)$ {
        try_files $uri /index.php$request_uri;
        expires 6M;
        access_log off;
    }

    location / {
        try_files $uri $uri/ /index.php$request_uri;
    }
}

Ścieżkę do gniazda FPM musisz dopasować do swojej wersji PHP. Na Debianie 13 nazywa się ono php8.4-fpm.sock, na Debianie 12 php8.2-fpm.sock, na Ubuntu 24.04 php8.3-fpm.sock, a na Ubuntu 22.04 php8.1-fpm.sock. Jeśli nazwa się nie zgadza, dostaniesz 502 Bad Gateway. Faktyczną nazwę pokaże:

systemctl enable --now php8.4-fpm
ls /run/php/

Pierwsza linia jest tu potrzebna, bo plik gniazda powstaje dopiero przy starcie usługi. Wcześniej /run/php/ jest albo pusty, albo w ogóle nie istnieje, a ls odpowiada No such file or directory. Na normalnym serwerze pakiet uruchamia usługę już podczas instalacji, ale po ponownej instalacji systemu albo w kontenerze nie jest to gwarantowane. Numer wersji w nazwie usługi dopasuj do swojej instalacji. Potem nginx -t i przeładowanie.

Instalacja, HTTPS i trusted_domains

Konfigurację możesz przeklikać w przeglądarce albo od razu załatwić w wierszu poleceń. Ten drugi wariant jest powtarzalny i da się go zapisać w skrypcie:

cd /var/www/nextcloud
sudo -u www-data php occ maintenance:install --database "mysql" --database-name "nextcloud" --database-user "nextcloud" --database-pass "TutajDlugieHaslo" --admin-user "admin" --admin-pass "InneDlugieHaslo" --data-dir "/var/nextcloud-data"

Są przy tym dwie pułapki. Po pierwsze polecenie musi być uruchomione z katalogu Nextclouda, inaczej PHP przerwie działanie błędem Fatal Error. Po drugie occ nigdy nie może działać jako root, bo wtedy pojawia się „Console has to be executed with the user that owns the file config/config.php”, a w najgorszym razie świeżo utworzone pliki należą potem do niewłaściwego użytkownika.

Teraz HTTPS. Bez certyfikatu aplikacje mobilne odmawiają współpracy, a Nextcloud ostrzega o tym w przeglądzie:

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

Przy kilku subdomenach opłaca się certyfikat wildcard. Dopisz potem w bloku serwera TLS nagłówek Strict-Transport-Security "max-age=15552000; includeSubDomains" always;, inaczej zostanie ci ostrzeżenie „The Strict-Transport-Security HTTP header is not configured to at least 15552000 seconds”.

Na koniec klasyk: otwierasz stronę pod inną nazwą niż przy instalacji i widzisz już tylko „You are accessing the site from an untrusted domain.” Nextcloud akceptuje wyłącznie nazwy hostów wpisane w trusted_domains. Dodanie bez ręcznej edycji pliku:

sudo -u www-data php occ config:system:set trusted_domains 1 --value=cloud.example.com
sudo -u www-data php occ config:system:get trusted_domains

Indeks liczy się od 0, a 0 jest zwykle już zajęte. Jeśli nadasz ten sam indeks dwa razy, nadpiszesz istniejący wpis i w pewnych okolicznościach sam się zablokujesz. Gdyby tak się stało: config/config.php to całkiem zwykły plik PHP, wpis możesz poprawić w nim edytorem. Ustaw dodatkowo overwrite.cli.url na docelowy adres HTTPS, inaczej zadania w tle będą generować linki z błędną nazwą hosta.

Rozmiar wysyłanych plików i limit pamięci

Domyślne ustawienia PHP są dla Nextclouda za ciasne. upload_max_filesize stoi zwykle na 2M, a memory_limit na 128M. Nextcloud zaleca co najmniej 512M pamięci, a w przeciwnym razie ostrzega komunikatem „The PHP memory limit is below the recommended value of 512MB”.

Są tu trzy miejsca i nie wystarczy ruszyć jednego z nich:

1. Konfiguracja FPM w /etc/php/<version>/fpm/php.ini: memory_limit = 512M, upload_max_filesize = 10G, post_max_size = 10G, max_execution_time = 3600. Potem zrestartuj FPM, samo przeładowanie nginx nie wystarczy.
2. Plik .user.ini w katalogu Nextclouda: Nextcloud dostarcza własne wartości, a ponieważ .user.ini obowiązuje na poziomie katalogu, wygrywa z globalnym php.ini. Właśnie na tym regularnie rozbija się szukanie błędu. Dopasuj wartości również tam. PHP trzyma ten plik w cache, domyślnie przez pięć minut, więc twoja zmiana zadziała z opóźnieniem.
3. Dyrektywa nginx client_max_body_size: jeśli jej brakuje albo jest za mała, wysyłanie urywa się z komunikatem „413 Request Entity Too Large”, zanim PHP w ogóle zostanie o cokolwiek zapytane.

Do sprawdzenia, co ostatecznie obowiązuje, przyda się strona Ustawienia administracyjne, bo tam widnieje faktycznie działający limit. W wierszu poleceń:

grep -E '^(memory_limit|upload_max_filesize|post_max_size)' /etc/php/8.4/fpm/php.ini

Pytaj wyraźnie o plik FPM, a nie o wiersz poleceń. php -r "echo ini_get('memory_limit');" czyta SAPI wiersza poleceń, a ta na wszystkich sprawdzonych dystrybucjach zgłasza -1, czyli brak limitu. Kto na tym polega, uzna wartość za wystarczającą i mimo to wpadnie później w błędy pamięci, bo w pliku FPM nadal stoi memory_limit = 128M. To, co naprawdę dociera do przeglądarki, pokaże php-fpm8.4 -i albo krótko podrzucony plik info.php z phpinfo(), który zaraz potem od razu kasujesz.

Jeśli przy wysyłaniu dużych plików proces zostaje ubity przez kernel, brakuje po prostu pamięci RAM. Wtedy doraźnie pomoże konfiguracja swapa, ale lepszym rozwiązaniem jest więcej RAM.

Przestawienie zadań w tle na cron

Po instalacji Nextcloud pracuje w trybie AJAX: zadania w tle wykonują się tylko wtedy, gdy ktoś ma akurat otwarty interfejs. To dlatego wyszukiwanie pełnotekstowe, prace porządkowe i powiadomienia na mało używanych instancjach pozornie w ogóle się nie dzieją. Przestaw to na prawdziwego crona, Nextcloud oczekuje uruchomienia co pięć minut. Podstawy znajdziesz w artykule konfiguracja zadania cron w Linuksie.

sudo crontab -u www-data -e

Tam wpisz:

*/5 * * * * php -f /var/www/nextcloud/cron.php

Potem poinformuj Nextclouda o zmianie trybu:

cd /var/www/nextcloud
sudo -u www-data php occ background:cron

Kto woli pracować bez demona cron, bierze usługę systemd z timerem. Unit nextcloudcron.service wywołuje /usr/bin/php -f /var/www/nextcloud/cron.php jako użytkownik www-data, a przypisany do niego timer ustawia OnBootSec=5min oraz OnUnitActiveSec=5min.

Jeśli ostrzeżenie „Last background job execution ran X hours ago. Something seems wrong” mimo to nie znika, sprawdzaj w tej kolejności: czy zadanie działa jako właściwy użytkownik? Czy ścieżka naprawdę istnieje? I rzecz najważniejsza: czy cron.php w ogóle daje się uruchomić w konfiguracji PHP dla wiersza poleceń, czy może brakuje tam modułu zainstalowanego wyłącznie dla FPM? Najuczciwszym testem jest ręczne wywołanie, bo wtedy widzisz każdy komunikat błędu otwartym tekstem:

sudo -u www-data php -f /var/www/nextcloud/cron.php

Odhaczanie ostrzeżeń z przeglądu

Lista w Ustawienia administracyjne i Przegląd nie jest ozdobą, każda linia ma konkretny powód. Najczęstsze pozycje i sposób ich usunięcia:

• „No memory cache has been configured”: APCu jest zainstalowane, ale nie wpisane do konfiguracji. occ config:system:set memcache.local --value='\OC\Memcache\APCu'. Żeby korzystały z tego również occ i przebiegi crona, ustaw dodatkowo apc.enable_cli=1 w /etc/php/<version>/mods-available/apcu.ini.
• „Transactional file locking is disabled”: zainstaluj Redis (apt-get install -y redis-server php-redis) i ustaw memcache.locking na \OC\Memcache\Redis. Na instancjach jednoosobowych można sobie to darować, ale gdy kilku użytkowników synchronizuje dane równocześnie, już nie.
• „Your web server is not properly set up to resolve /.well-known/caldav”: brakuje przepisań w bloku location ^~ /.well-known. Sprawdzisz to bezpośrednio przez curl -I https://cloud.example.com/.well-known/caldav, oczekiwana jest odpowiedź 301 na /remote.php/dav/.
• „Your installation has no default phone region set”: occ config:system:set default_phone_region --value="AT", dla Polski PL. Wartość to kod kraju według ISO 3166-1.
• „Server has no maintenance window start time configured”: occ config:system:set maintenance_window_start --type=integer --value=1. Wartość to godzina startu w UTC, kosztowne zadania dobowe ruszają wtedy nocą, a nie w środku pracy.
• „The database is missing some indexes”: occ db:add-missing-indices, a do kompletu occ db:add-missing-columns i occ db:add-missing-primary-keys. Na dużych instancjach te polecenia działają wolno, ale są bezpieczne.
• „PHP does not seem to be setup properly to query system environment variables”: w pliku puli FPM /etc/php/<version>/fpm/pool.d/www.conf odkomentuj linię env[PATH] = /usr/local/bin:/usr/bin:/bin i zrestartuj FPM.
• „Module php-imagick in this instance has no SVG support”: to nie jest błąd Nextclouda, tylko brakująca biblioteka delegata w ImageMagick. Jeśli nie potrzebujesz podglądów SVG, możesz zostawić to ostrzeżenie tak, jak jest.

Po czym poznasz, że naprawdę działa

Cztery sprawdzenia, które razem wzięte dają wiarygodny obraz:

cd /var/www/nextcloud
sudo -u www-data php occ status
sudo -u www-data php occ check
sudo -u www-data php occ config:app:get core lastcron

occ status musi zgłosić installed: true oraz oczekiwaną wersję, a occ check nie powinien wypisać niczego. Trzecie polecenie zwraca uniksowy znacznik czasu. Przelicz go: nie może być starszy niż pięć minut, wtedy twój cron faktycznie pracuje.

Z zewnątrz:

curl -s https://cloud.example.com/status.php

Odpowiedzią jest obiekt JSON z "installed":true, "maintenance":false i numerem wersji. Jeśli wraca stąd HTML, któraś z twoich reguł location działa za szeroko. Jeśli wraca przekierowanie na stronę logowania, wszystko jest w porządku, tylko trafiłeś pod zły adres.

Na koniec test praktyczny, którego nie zastąpi żadna strona statusu: wyślij przez interfejs webowy plik o rozmiarze kilku gigabajtów, a potem zsynchronizuj go klientem desktopowym. Dopiero wtedy okaże się, czy client_max_body_size, post_max_size, limity czasu i wolne miejsce na dysku pasują do siebie. Jeśli nagle wszystko staje, warto zajrzeć do artykułu o pełnych dyskach, bo Nextcloud zakłada podglądy i wersje plików, które rosną w zauważalnym tempie.

Kiedy coś pójdzie nie tak

Nextcloud zapisuje logi do /var/nextcloud-data/nextcloud.log, czyli do twojego katalogu danych, a nie do /var/log. To pierwszy plik, do którego powinieneś zajrzeć, a nie log serwera nginx. Dla czytelnej postaci:

sudo -u www-data php occ log:watch

Jeśli po przerwanej aktualizacji instancja utknie w trybie serwisowym, wyciągnie ją stamtąd occ maintenance:mode --off. Jeśli interfejs jest już całkiem niedostępny, ustaw 'maintenance' => false bezpośrednio w config/config.php.

Zanim zaczniesz grzebać w bazie danych albo w konfiguracji, zabezpiecz jedno i drugie. Sama kopia katalogu nie wystarczy, bo Nextcloud bez pasującej bazy danych jest bezwartościowy:

sudo -u www-data php occ maintenance:mode --on
sudo mariadb-dump --single-transaction nextcloud > /root/nextcloud-db.sql
sudo -u www-data php occ maintenance:mode --off

I rada zasadnicza: dokończ budowę serwera, zanim udostępnisz go publicznie. Firewall, zabezpieczony dostęp SSH oraz punkty z listy kontrolnej dla nowych serwerów root należą przed pierwsze logowanie, a nie po nim. Instancja Nextclouda z domyślnym hasłem zostaje znaleziona w ciągu kilku godzin.