ODROID-HC4: Btrfs errors on both-disk storage after power outage

I’m running Syncloud on an ODROID-HC4, booting from microSD, with two Seagate ST4000NE001-2MA1 drives. After a power outage, SSH and the web interface were initially unavailable. The system now boots and Nextcloud is accessible, but Syncloud’s storage page shows a red exclamation mark for both disks.

I have not formatted, initialized, rebuilt, scrubbed, or repaired anything. I’d like to avoid further reboots if possible, since the HDDs are connected and the system has already been restarted several times.

What I’ve found so far:

  • The drives appear as /dev/sda and /dev/sdb.
  • /dev/sda is mounted as Btrfs at /opt/disk/external.
  • The mounted filesystem’s Btrfs sysfs device list includes both drives.
  • System logs report Btrfs errors on sdb, including parent transid verify failed and error loading props.
  • /proc/mdstat is missing, so I can’t confirm the storage profile.
  • The microSD root partition, /dev/mmcblk0p2, has reported ext4 errors: bad block bitmap checksum and a corrupted orphan inode list.
  • btrfs and smartctl are not installed.

Updates and backups:

  • Syncloud System update to version 3165 completed.
  • Syncloud app updates completed except for two apps, which I’ve deactivated.
  • Nextcloud update from version 1014 to 1036 failed twice.
  • Syncloud’s built-in backup function completed successfully.

Could you suggest a safe, preferably read-only and no-reboot set of diagnostics to run, and advise what output or logs to share? In particular, I’d like to:

  1. Confirm the intended storage layout/profile and which devices belong to the filesystem.
  2. Check both HDDs’ health and determine whether the Btrfs errors suggest a failing disk or filesystem damage.
  3. Assess the microSD/ext4 errors without risking the data.
  4. Find logs or details that may explain the failed Nextcloud update.

Please identify any commands that are strictly read-only and flag anything that could write to the disks or make recovery harder. I can share relevant command output and logs here, with personal information removed.

Thanks for the report, I went through your logs.

The errors come from the second disk slot (sdb): its SATA connection keeps resetting under load, and only while the Nextcloud updates were running. The first disk has no such errors. Your two disks mirror each other, so the data has a second copy.

First, a simple test to see whether it is the disk or the slot:

  1. Copy anything you cannot lose off the device first. The built-in backup saves app settings, not your Nextcloud files, and it is stored on these same disks.
  2. Shut down, unplug the power, swap the two disks between the slots, and boot. Swapping is safe: Btrfs finds its disks by ID, not by slot.
  3. Do not retry the Nextcloud update yet - it reads the whole disk.
  4. Use the device normally for a while, then send a new device report from Settings - Support.

If the errors move with the disk, the disk is the problem. If they stay on the second slot, it is the board or its power.

If /data does not come up after the swap, stop there and post here - please do not try to mount it by hand.

I’ve set up Syncloud in a VM on my laptop so I can test restoring the app backups before doing hardware tests on the original device. I understand the backups don’t include the Nextcloud files; I have those stored on a separate hard drive.

I’m having trouble restoring the Bitwarden and Nextcloud app backups. Both apps work after a fresh install, but not after restoring a backup. Bitwarden shows:

Error 502 — App is not available or still starting.

Nextcloud shows the same error. At times, it also says it’s upgrading the PostgreSQL database, but it remains on that message indefinitely. I wonder if the restore is failing because the backup was made with a version one release older than the version currently installed.

I’ve sent the logs from the VM. I’d prefer to get the app restores working before testing the disks in the original device.

One other concern: I can’t prevent Nextcloud from updating on the original device. I think automatic updates may be enabled by default, and I can’t find a way to disable them in the UI. Being able to turn off automatic app updates from the UI would be a useful feature request, though that’s a separate topic.

trouble restoring the Bitwarden

Bitwarden backup was actually broken on Syncloud platform side, the fix should be released, system v3175 should be used to create a new backup so it can be restored.

Nextcloud shows the same error

Let me check the logs you sent

Good point, I did now and it restores successfully, but I can’t login with former account that should be restored as well, I would guess. Vaultwarden UI says “Ein Fehler ist aufgetreten. Error saving device”. Or does it need data from HDD Storage? I just sent VM logs again.

Cross device backup had an issue, the fix is coming, in this case backup is good but it could not be restored on another device.

Platform v3185 should be fixed to restore properly bitwarden backup.

Also Nextcloud backups were broken for some time so you better create a new backup as well.

Thank you. To restore worked for both backups now as well. I will make the hardware tests and let you know.

I did now and sent logs. I can still open nextcloud files.

No new errors yet, you need to use it for a day or two and send the report again please.

just sent logs again, they show BTRFS error (device sdb)

The problem follows the slot, not the disk.

Before the swap, the disk in SATA port 2 kept losing its connection. After the swap, the other disk is now in port 2 and does exactly the same: 4 link resets on 28 Oct around 23:18, 2 on 29 Oct around 23:33 and 14 on 30 Oct around 23:28. Port 1 had no errors at all. The errors are signal drops on the SATA link itself, not bad sectors, so both disks look fine. The likely cause is the port 2 connector on the board, or the power supply.

The btrfs errors you saw are a side effect. While port 2 keeps dropping out, that disk misses writes. Btrfs then repairs from the other disk where it can, but while port 2 is down there is no second copy, so some reads fail.

To find which physical disk is on port 2, run this:

lsblk -d -o NAME,HCTL,SERIAL,MODEL /dev/sda /dev/sdb

The line whose HCTL starts with 1: is the disk on port 2. Its serial number is printed on the disk label, so the connector under that disk is the one to look at.

What I would do, in this order:

  1. If your data is not copied off yet, do that first.
  2. Power off, unplug, take that disk out and look at the board connector under it. Look for a loose or tilted connector, or one that moves when touched. On the HC4 the disks only hang on that connector, so a knock or a sideways push on a 3.5" disk can crack its solder joints.
  3. Check that you are using the original 15V 4A power adapter.
  4. Please do not run with only one of the two disks.