Sorry to hear you’re facing problems
In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:
Or for longer, use three backticks above and below the code snippet:
longer example here
Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can
Nextcloud version (eg, 12.0.2): 15.0.5
Operating system and version (eg, Ubuntu 17.04): Ubuntu 16.0.4
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.18
PHP version (eg, 7.1): 7.0.33
The issue you are facing:
Nextcloud has been working for a couple of year on my server, but failed this morning. Yesterday I upgraded three apps and afterwards I upgraded Nextcloud from 15.0.2 to 15.0.5. This morning Nextcloud failed most likely due to a MySQL issue. The MySQL error.log is being written to constantly and mentions issues with the authtoken table. When issuing a “show tables” command within the mysql cli, the authtoken table is shown amongst all the other Nextcloud tables. When issuing a “CHECK TABLE oc_authtoken” command, MySQL says “Table ‘owncloud.oc_authtoken’ doesn’t exist”.
I’ve put Nextcloud into maintenance mode and have tried the “sudo -u www-data php occ maintenance:repair” command. It shows the following:
Nextcloud is in maintenance mode - no apps have been loaded
Failed to load repair step for audioplayer: Repair step ‘OCA\audioplayer\Migration\Migration’ is unknown
Failed to load repair step for dav: Repair step ‘OCA\DAV\Migration\FixBirthdayCalendarComponent’ is unknown
Failed to load repair step for dav: Repair step ‘OCA\DAV\Migration\CalDAVRemoveEmptyValue’ is unknown
Failed to load repair step for dav: Repair step ‘OCA\DAV\Migration\BuildCalendarSearchIndex’ is unknown
Failed to load repair step for dav: Repair step ‘OCA\DAV\Migration\RefreshWebcalJobRegistrar’ is unknown
Failed to load repair step for dav: Repair step ‘OCA\DAV\Migration\RemoveClassifiedEventActivity’ is unknown
Failed to load repair step for files_sharing: Repair step ‘OCA\Files_Sharing\Migration\OwncloudGuestShareType’ is unknown
Failed to load repair step for files_sharing: Repair step ‘OCA\Files_Sharing\Migration\SetPasswordColumn’ is unknown
Failed to load repair step for oauth2: Repair step ‘OCA\OAuth2\Migration\SetTokenExpiration’ is unknown
Failed to load repair step for twofactor_backupcodes: Repair step ‘OCA\TwoFactorBackupCodes\Migration\CheckBackupCodes’ is unknown
- Repair MySQL collation
- All tables already have the correct collation -> nothing to do
- Repair mime types
- Clean tags and favorites
- 0 tags of deleted users have been removed.
- 0 tags for delete files have been removed.
- 0 tag entries for deleted tags have been removed.
- 0 tags with no entries have been removed.
- Repair invalid shares
- Remove shares of a users root folder
- Move .step file of updater to backup location
- Fix potential broken mount points
- No mounts updated
- Repair invalid paths in file cache
- Add log rotate job
- Clear frontend caches
- Image cache cleared
- SCSS cache cleared
- JS cache cleared
- Clear every generated avatar on major updates
- Add preview background cleanup job
- Queue a one-time job to cleanup old backups of the updater
- Repair pending cron jobs
- No need to repair pending cron jobs.
- Extract the vcard uid and store it in the db
The messages (they keep repeating) in the MySQL error.log is somewhat ominous. Other than page dumps, it shows the following:
[Note] InnoDB: Uncompressed page, stored checksum in field1 2278197719, calculated checksums for field1: crc32 1598924062/2669165296, innodb 2251606416, none 3735928559, stored checksum in field2 4098179892, calculated checksums for field2: crc32 1598924062/2669165296, innodb 2190848791, none 3735928559, page LSN 3 2016071666, low 4 bytes of LSN at page end 2006634632, page number (if stored to page already) 4, space id (if created with >= MySQL-4.1.1 and stored already) 705
InnoDB: Page may be an index page where index id is 1497
[Note] InnoDB: Index 1497 is
authtoken_token_index in table
[Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
[ERROR] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=705, page number=4]. You may have to recover from a backup.
[Note] InnoDB: Page dump in ascii and hex (16384 bytes):
… (page dump) …
I’m no db expert. I’m sort of hoping it might be possible to simply remove that authtoken table and then have Nextcloud re-create it, f.ex. with the occ repair option.
I’d rather ask here for suggestions as to what to do before I potentially do something stupid.
Is this the first time you’ve seen this error? (Y/N): Y
Steps to replicate it:
- I’d rather not
The output of your Nextcloud log in Admin > Logging:
The output of your config.php file in
/path/to/nextcloud (make sure you remove any identifiable information!):
The output of your Apache/nginx/system log in