Unable to edit files, changes lost on reboot

LSIO Discussion Container Support
1

I can’t edit text files via the nextcloud web ui using the “Text” or “Notes” apps.

  • I can create them (“New text file”), and if I select one of the templates, the file is written to disk with the template data.
  • If I then edit the file via the web ui, the changes are not saved to disk and are lost when rebooting the container. They do show up in the file if I open it on the web ui, but are lost at next reboot (or maybe sooner, haven’t done longterm tests)
  • I can upload files via the web ui (and the desktop and mobile clients)

My docker-compose: pastebin

Nextcloud.log during a creation and editing of a text file: pastebin
(there’s a lot of it)

In the log file, there is stuff like this (I have bolded the parts I suspect):

“reqId”:“mf5NHvBOIdZE3GTFuy8E”,“level”:0,“time”:“2025-01-28T13:37:26+00:00”,“remoteAddr”:“192.89.66.202”,“user”:“username”,“app”:“no app in context”,“method”:“POST”,“url”:“/ocs/v2.php/apps/files/api/v1/templates/create”,“message”:"dirty table reads: SELECT filecache.fileid, storage, path, path_hash, filecache.parent, filecache.name, mimetype, mimepart, size, mtime, storage_mtime, encrypted, etag, filecache.permissions, checksum, unencrypted_size, metadata_etag, creation_time, upload_time, meta.json AS meta_json, meta.sync_token AS meta_sync_token FROM *PREFIX*filecache filecache LEFT JOIN *PREFIX*filecache_extended fe ON filecache.fileid = fe.fileid LEFT JOIN *PREFIX*files_metadata meta ON filecache.fileid = meta.file_id WHERE (storage = :dcValue1) AND (path_hash = :dcValue2)",“userAgent”:"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101

I can’t find anything I recognize as a problem in the log file.

How to troubleshoot?

2

looks like you have a database issue. do you do auto upgrades of containers?

3

Ah, didn’t spot that. No, I don’t do auto upgrades. Although I haven’t specified a version in the docker-compose.yml, does that mean it automatically pulls the newest one?

4

Here’s docker logs mariadb:

docker logs mariadb
[migrations] started
[migrations] no migrations found
───────────────────────────────────────

  ██╗     ███████╗██╗ ██████╗
  ██║     ██╔════╝██║██╔═══██╗
  ██║     ███████╗██║██║   ██║
  ██║     ╚════██║██║██║   ██║
  ███████╗███████║██║╚██████╔╝
  ╚══════╝╚══════╝╚═╝ ╚═════╝

Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID: 1000
User GID: 1000
───────────────────────────────────────
Linuxserver.io version: 10.11.10-r0-ls162
Build-date: 2024-11-12T07:43:21+00:00
───────────────────────────────────────

[custom-init] No custom files found, skipping…
250125 14:28:37 mysqld_safe Logging to ‘/config/databases/17325de1474e.err’.
250125 14:28:37 mysqld_safe Starting mariadbd daemon with databases from /config/databases
Connection to localhost (::1) 3306 port [tcp/mysql] succeeded!
[ls.io-init] done.

5

only if you do a docker compose pull and docker compose up -d though if you’re using any docker UI it might be doing it without you knowing. Either way, updating a database while it’s being accessed will cause corruption.

take a look at your /config/databases/17325de1474e.err file and see if anything jumps out. You could try restoring a backup from the last time it worked too

6

Thanks. I tried to restore backups, but it seems they are all broken as well. I assume my method of backing up (I rsync the volumes while they are running) is… suboptimal.
Can I try to fix the database somehow?

7

you need to handle backups how mariadb tells you to handle backups; usually via mysqldump or other things. Backing Up and Restoring Databases - MariaDB Knowledge Base

you could try a repair, just google mariadb repair, but this is a bit out of scope for us as it’s not a container issue.

A few things to keep in mind,

  1. don’t update mariadb while things are accessing it (stop containers that access it before doing ANY maintenance on the db, to include restarting, stopping, updating, and repairing)
  2. take proper backups of your database following the link above
8

Yeah, my bad. I spent half a day trying to fix an unfixable database, got fed up with that and set up the nextcloud server from scratch in like 30 mins :smile:

I have now set up proper backup: stop nextcloud, dump the sql, rename the sql to include date and move it to a properly backed-up location.

Let my tale be a warning to others like me :point_up:

9

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.