Operating system and version (e.g., Ubuntu 24.04):
Arch Linux, but docker deployment
Web server and version (e.g, Apache 2.4.25):
Apachen, AIO
Reverse proxy and version _(e.g. nginx 1.27.2)
Traefik
PHP version (e.g, 8.3):
AIO
Is this the first time you’ve seen this error? (Yes / No):
No error, rather a configuration questions
When did this problem seem to first start?
No problem, rather a configuration question
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
AIO
Are you using CloudfIare, mod_security, or similar? (Yes / No)
No
Summary of the issue you are facing:
In an AIO installation, the database is owned by the container
nextcloud-aio-database. The database is stored in a docker volume. If docker volumes happen to be stored on a btrfs file system, I would have expected that the database file is created with copy-on-write disabled. That is, however, not the case.
Now the question. Is that a conscious decision from the AIO team or would it be better to change it?
Steps to replicate it (hint: details matter!):
Deploy an AIO installation.
cd into your docker volumes folder or exec into the database container.
Inspect the xattr of the postgres database with lsattr.
AIO’s db container is just leveraging the upstream PostgreSQL base image. That image’s docs don’t discuss the topic anywhere either that I could find.
Some Linux distributions that use BTRFS by default already automatically disable COW on select volumes that are likely to contain VM images and Docker volumes. SUSE for example[1]. On those it’s presumably not going to arise (at least in a typical deployment).
I’m not aware of a conscious decision outright for AIO to overlook this. It probably just hasn’t come up enough and/or is safer for AIO to leave alone low level host system specific matters.
If you want to try it, there are multiple ways of adjusting COW for Docker volumes or the specific bind mount folders containing associated with the containers/stacks you’re concerned with. Just make sure to do it before going live since it won’t actually change for already populated folders/volumes.
As an aside, my purely spectator impression, is that there have been a mixture of things done on both the filesystem and db side to over the years to diminish some of the COW/DB interactions.
I also have the impression, that databases and CoW filesystems play better these days then they might have used to. I e.g., read a post about performance measurement with sqlite where the difference was there, but not massive.
Anyhow, thank you for your answer. I might change the db-file to non CoW, if I find time.
