Server Details
- OS: Artix Linux (Arch-based, rolling release)
- Install Method: Docker/Compose (latest version)
- Reverse Proxy: NGINX (latest version)
- Database: MariaDB v10.6.20
- Nextcloud: v29.0.11 (Docker – barebones)
- Php: v8.2.27
- Apache: Unable to find version included in Docker image.
- First time encountering this issue.
Background
I’m running Nextcloud behind NGINX (reverse proxy). NGINX handles SSL termination in my case. Nextcloud, Redis, and NGINX run as Docker containers. This instance is only reachable locally (not exposed to the Internet), and is sometimes accessed over VPN. I recently had to restore multiple services, due to some HDDs dying. That was initially noted here.
The Issue
A few days ago, I started seeing some MariaDB-related errors in the Nextcloud logs:
At first, I could only see the entries mentioning oc_filecache. I emptied the corrupted table and ran occ files:scan --all -vvv, followed by occ maintenance:repair. I received no errors after running these two commands, and new errors stopped appearing in the Nextcloud logs that evening.
A day or two later, I checked logs again. This time, I saw errors mentioning oc_files_versions and oc_calendarobjects_props. For oc_files_versions, I’m considering running occ files_versions:cleanup – assuming that will clear out all file versions created. However, the restore process for oc_calendarobjects_props has me second-guessing myself.
With InnoDB, you can detect corruption. But there’s no easy option for simply repairing in-place.
Furthermore, oc_calendarobjects_props doesn’t support OPTIMIZE:
MariaDB [nextcloud]> OPTIMIZE TABLE oc_calendarobjects_props;
+------------------------------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+------------------------------------+----------+----------+-------------------------------------------------------------------+
| nextcloud.oc_calendarobjects_props | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| nextcloud.oc_calendarobjects_props | optimize | error | Got error 106 "Unknown error" from storage engine InnoDB |
| nextcloud.oc_calendarobjects_props | optimize | status | Operation failed |
+------------------------------------+----------+----------+-------------------------------------------------------------------+
3 rows in set, 1 warning (0.209 sec)
With how that failed (and assuming that the command re-creates the table, before copying the previous contents back to it), I’m thinking that the current table’s contents are beyond saving. I think that I’ll have to restore its contents from a previous backup instead.
Possible Solution
From what I was able to retrieve from MariaDB, all affected tables appear to be non-partitioned. After briefly researching online, I came across this.
According to that article, I may need to do something along the lines of:
use nextcloud;
# Not sure it'd be safe to use TRUNCATE, since index and B-tree are corrupted.
DROP TABLE IF EXISTS 'oc_calendarobjects_props';
CREATE TABLE 'oc_calendarobjects_props' (
'id' bigint(20) unsigned NOT NULL AUTO_INCREMENT,
'calendarid' bigint(20) NOT NULL DEFAULT 0,
'objectid' bigint(20) unsigned NOT NULL DEFAULT 0,
'name' varchar(64) DEFAULT NULL,
'parameter' varchar(64) DEFAULT NULL,
'value' varchar(255) DEFAULT NULL,
'calendartype' int(11) NOT NULL DEFAULT 0,
PRIMARY KEY ('id'),
KEY 'calendarobject_index' ('objectid','calendartype'),
KEY 'calendarobject_name_index' ('name','calendartype'),
KEY 'calendarobject_value_index' ('value','calendartype'),
KEY 'calendarobject_calid_index' ('calendarid','calendartype')
) ENGINE=InnoDB AUTO_INCREMENT=112788 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=COMPRESSED;
ALTER TABLE 'oc_calendarobjects_props' DISCARD TABLESPACE;
# Copy oc_calendarobjects_props.ibd and oc_calendarobjects_props.cfg from the backup to the corresponding directory in MariaDB.
ALTER TABLE 'oc_calendarobjects_props' IMPORT TABLESPACE;
Can Nextcloud re-populate oc_calendarobjects_props if I re-create it as an empty table (or just drop the table)?
Am I going about this correctly? Or do I need to re-think my approach?
EDIT: Nextcloud 29.X was unable to re-create oc_calendarobjects_props on its own, after dropping the table. It has to be manually re-created by the DBA.