Upgrade von 32.0.3.2 zu 32.0.5.0

ℹ️ Support
, ,
1

Hallo,

Nextcloud läuft als Docker Container.

Beim neuestem Upgrade läuft der Startvorgang in einer Endlosschleife:

Initializing nextcloud 32.0.5.0 …
Upgrading nextcloud from 32.0.3.2 …
rsync: [generator] delete_file: rmdir(tmp) failed: Device or resource busy (16)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.4.1]
Initializing nextcloud 32.0.5.0 …
Upgrading nextcloud from 32.0.3.2 …
rsync: [generator] delete_file: rmdir(tmp) failed: Device or resource busy (16)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.4.1]
Initializing nextcloud 32.0.5.0 …
Upgrading nextcloud from 32.0.3.2 …

Wenn das alte Image geladen wird, dann läuft Nextcloud fehlerfrei an.

In der alten Version wurden bereits alle Apps aktualisiert.
Der Befehl …
./occ status
… liefert keine Auffälligkeiten.

Weiß jemand, wie das Upgrade durchgeführt werden kann?

2

How are your volumes mounted? Are they on a network store (NFS, SMB) or similar perhaps?

Something is unusual about the underlying storage.

Post your Docker Compose and share some details about your Docker host.

3

Hallo jtr,

die Volumes sind direkt eigebunden. Nextcluod und die Volumes befinden sich alle auf einem Raid-Laufwerk,

version: ‘3.8’
services:
nextcloud:
image: nextcloud:latest
container_name: cloudprivat
restart: unless-stopped

# ---- 1. Watchtower‑Label ---------------------------------------------
labels:
  com.centurylinklabs.watchtower.monitor-only: "true"

# ---- 2. Umgebungsvariablen -------------------------------------------
environment:
  - PHP_MEMORY_LIMIT=4G
  - PHP_UPLOAD_LIMIT=100G
  - PHP_MAX_EXECUTION_TIME=7200
  # ---- OPcache ----------------------------------------------------
  - PHP_OPCACHE_ENABLE=1
  - PHP_OPCACHE_MEMORY_CONSUMPTION=2048M  # in MB (z. B. 256 MB)
  - PHP_OPCACHE_VALIDATE_TIMESTAMPS=0   # kein Zeitstempel‑Check bei jedem Request
  - PHP_OPCACHE_REVALIDATE_FREQ=2       # nur alle 2 Sekunden prüfen
  - PHP_CHILDREN_MAX_BODY=18G
  - PHP_MAX_CHILDREN=60
  - PHP_REQUEST_TERMINATE_TIMEOUT=7300

# ---- 3. Volumes -------------------------------------------------------
volumes:
  - ./data:/var/www/html/data:rw
  - ./themes:/var/www/html/themes:rw
  - ./config-apache/apache2:/etc/apache2:rw
  - ./html:/var/www/html:rw
  - ./config:/var/www/html/config:rw
  - ./custom_apps:/var/www/html/custom_apps:rw

# ---- 4. tmpfs‑Mount (RAM‑Cache für temporäre Dateien) -----------------
tmpfs:
  - /tmp:size=12G                # 512 MiB im RAM, passt an deine Hardware an
  - /var/www/html/tmp:size=6G    # Nextcloud’s own temp dir

# ---- 5. Optional: CPU‑Limit ------------------------------------------
# Bei NanoCPUs nicht möglich, da dem Kernel Flags fehlen.
# Diese sind nur im Standard- oder Pro-Modell von Synology NAS vorhanden
#deploy:
#  resources:
#    limits:
#      cpus: '2'                    # maximal 2 CPUs (bei Swarm)
#    reservations:
#      cpus: '0.5'

# ---- 6. Netzwerker ---------------------------------------------------
networks:
  net188-1:
    ipv4_address: 192.168.1.3

networks:
net188-1:
external: true

Die Cloud läuft auf einem Synology NAS DSM7.

Bisher gab es kaum Probleme beim Upgrade, da nach einem Docker-Container-Upgrade automatisch das Upgrade von der Cloud aufgerufen wurde.

4

It may be related to this; normally the image you’re using expects there not to be unexpected folders in /var/www/html. During upgrades it’ll wipe them out.

https://github.com/nextcloud/docker?tab=readme-ov-file#custom-volumes

5

Hallo jtr,

im Pfad /var/www/html befinden sich nur die originale Dateien von nextcloud. Es wurden keine weiteren Dateien hinzugefügt.

6

versuch’ doch (vorsichtig!) mal, die inkriminierte Ressource von Hand zu löschen bzw. zu unmounten oder lass rsync mit mehr Output/Log laufen, um herauszufinden, was den Fehler verursacht.

Wenn zB ein tmpfs in /whatever/tmp gemountet ist, lässt sich /whatever/tmp nicht löschen.

7

Hallo pete.dawgg,

derzeit läuft eine Wiederherstellung der Dateien von einem Online-Backup. Das dauert, weil rund 480GB erst wieder über Internet übertragen werden müssen.

Bei den vergeblichen Upgrade-Vorgängen wurden alle Dateien gelöscht.

Zur Not werde ich die Cloud nochmal neu aufbauen müssen und die Dateien wieder einhängen.

8

Nach dem Backup wird wieder die Version 31 gefordert, zu installieren, da Nextcloud annimmt, es sei erst Version 30 vorhanden. Die Datenbank ist jedoch schon auf Version 32.0.3.2.

Nach dem das Docker-Image der Version 31 geladen wurde, kommen natürlich viele Datenbank-Fehler. Von der Datenbank existiert ein Backup mit dem Stand vor dem fehlgeschlagenem Upgrade.

Sollte man nun Nextcloud einfach neu in der aktuellen Version mit einer neuen Datenbank installieren?

Sobald alles läuft, könnte man die Dateien wieder “zuweisen” und anschließend die alte Datenbank von Version 32.0.3.2 zuweisen.

Würdet Ihr das so ähnlich durchführen?

9

Your Docker compose file creates /var/www/html/tmp since you have tmpfs in it.

10

Nach drei Tagen läuft nun wieder die alte Version 32.0.3.2.

Wenn das aktuelle Image jedoch wieder aktiviert wird, hängt der Container in einer Endlosschleife fest, in der ein Upgrade versucht wird, auszuführen.

Mit NEXTCLOUD_UPDATE=0 sollte ein automatisches Upgrade beim starten verhindert werden.

Trotz Angabe von NEXTCLOUD_UPDATE=0 wird automatisch versucht, ein Upgrade durchzuführen.

Es war beabsichtigt, nach dem Starten mit “occ upgrade” gezielt upzugraden.Auf diese Weise können zumindest die Fehlermeldungen nachgelesen werden.

11

Ziwischenzeitlich wurde eine Config-Einstellung entdeckt, mit der ein automatisches Upgrade verhindert werden kann:

Auf dieser Webseite wird erläutert, dass durch setzen der Config-Einstellung

‘updatechecker’ => false,

ein automatisches Upgrade unterbunden werden kann.

Nach dem Neustart werden folgende Meldungen protokolliert:

cloudprivat | Warning: /var/www/html/config/redis.config.php differs from the latest version of this image at /usr/src/nextcloud/config/redis.config.php
cloudprivat | Warning: /var/www/html/config/reverse-proxy.config.php differs from the latest version of this image at /usr/src/nextcloud/config/reverse-proxy.config.php
cloudprivat | Warning: /var/www/html/config/s3.config.php differs from the latest version of this image at /usr/src/nextcloud/config/s3.config.php
cloudprivat | Warning: /var/www/html/config/smtp.config.php differs from the latest version of this image at /usr/src/nextcloud/config/smtp.config.php
cloudprivat | Warning: /var/www/html/config/upgrade-disable-web.config.php differs from the latest version of this image at /usr/src/nextcloud/config/upgrade-disable-web.config.php
cloudprivat | => Searching for hook scripts (*.sh) to run, located in the folder “/docker-entrypoint-hooks.d/before-starting”

Weiß jemand, wie es nun weiter gehen kann?