owncloud / owncloud/core

oC loses public link after a DB recover from a filesystem snapshot

Open
#38,559 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Type:Bug
Dominant language
PHP
Stars
8.8k
Forks
2.1k
Avg merge
20h 7m
Merged PRs (30d)
41

Description

Steps to reproduce
  1. Create a public link which is pwd protected and has an expiration date
  2. Running hourly snapshots of the filesystem where the database is located (no DB shutdown)
  3. Wait for hours (but do nothing on the system). I waited for more than three hours
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.