oC loses public link after a DB recover from a filesystem snapshot
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 8.8k
- Forks
- 2.1k
- Avg merge
- 20h 7m
- Merged PRs (30d)
- 41
Description
Steps to reproduce
- Create a public link which is pwd protected and has an expiration date
- Running hourly snapshots of the filesystem where the database is located (no DB shutdown)
- Wait for hours (but do nothing on the system). I waited for more than three hours
- Restore the database from snapshot
Expected behaviour
ownCloud should still have the public link post recovery
Actual behaviour
The DB needed a sudo mysqld_safe --tc-heuristic-recover=COMMIT (ok, no worries)
But the public link was gone. One can argue that it was because using snapshots is like a dirty shutdown, but on the other hand, the link should have been committed to the DB securely, at least after the hours between link creation and recover from snapshot...
My worry is the following. A filesystem snapshot where the DB resides behaves the same like a power loss with regards the state of the DB files. In this case, customers would not know which things are in the DB an which are not. My assumption would be, that all recent DB changes are either committed or need a rollback (ok) - but those changes made hours before shoud be definitely in!
[Note] InnoDB: Starting recovery for XA transactions...
mysqld[1494039]: 2021-03-21 18:46:42 0 [Note] InnoDB: Transaction 613722999 in prepared state after recovery
[Note] InnoDB: Transaction contains changes to 1 rows
mysqld[1494039]: 2021-03-21 18:46:42 0 [Note] InnoDB: 1 transactions in prepared state after recovery
mysqld[1494039]: 2021-03-21 18:46:42 0 [Note] Found 1 prepared transaction(s) in InnoDB
mysqld[1494039]: 2021-03-21 18:46:42 0 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down >
mysqld[1494039]: 2021-03-21 18:46:42 0 [ERROR] Aborting
Link to MariaDB XA Transactions
Server configuration
Operating system: U20.04
Web server: nginx
Database: mariadb
PHP version: 7.4
ownCloud version: 10.6
Updated from an older ownCloud or fresh install: updated
Where did you install ownCloud from: tar
Signing status (ownCloud 9.0 and above): all green
The content of config/config.php:
List of activated apps:
Are you using external storage, if yes which one: local/smb/gd
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Opera
Operating system: W10x64
Logs
Web server error log
not relevant
ownCloud log (data/owncloud.log)
not relevant
Browser log
not relevant
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source files, tests, or entry points are named. Start by reproducing the public-link loss with MariaDB after restoring a filesystem snapshot, then trace the recovery and public-link persistence behavior. Done means a password-protected, expiring public link remains available after recovery without manual transaction recovery.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- mariadb, php
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100