# SOLVED! (post formerly titled as "BTRFS issue: open\_ctree failed; bad tree block start; unmountable"
**URL:** https://discourse.nixos.org/t/solved-post-formerly-titled-as-btrfs-issue-open-ctree-failed-bad-tree-block-start-unmountable/59604
**Category:** Help
**Created:** [January 31, 2025, 6:48am UTC](https://discourse.nixos.org/t/solved-post-formerly-titled-as-btrfs-issue-open-ctree-failed-bad-tree-block-start-unmountable/59604 "2025-01-31T06:48:05Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@nPrevail](https://discourse.nixos.org/u/nPrevail)
#### Post date: [January 31, 2025, 6:48am UTC](https://discourse.nixos.org/t/solved-post-formerly-titled-as-btrfs-issue-open-ctree-failed-bad-tree-block-start-unmountable/59604/1 "2025-01-31T06:48:05Z")
EDIT:
While I was in the middle of writing this post, I was also trying a list of solutions I found on this link:
[https://en.opensuse.org/SDB:BTRFS#How\_to\_repair\_a\_broken/unmountable\_btrfs\_filesystem](https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken/unmountable_btrfs_filesystem)
The solution to my problem was the `btrfs rescue zero-log /dev/sda1` method.
I was incredibly skeptical at first, because one solution after the other was not fixing it, until I came across the aforementioned one.
If anyone come across any issues with BTRFS, consider these solutions!
This guide also does an amazing job indicating “warnings” on the solutions as well, especially with the “forbidden” `check --repair` one, which I hope no one ever has to “roll the dice” on.
I remember doing it once, and it really messes up your drive. I had no idea what I was doing back then…
Hope this helps folks!
Cheers!
* * *
I’ve come across this issue a few times; not sure why or how it happens. Usually occurs after running `sudo nixos-rebuild switch --upgrade` and alike.
Here’s the details:
NVMe SSD; luks2 encrypted btrfs drive.
I usually use it externally via M.2 NVMe drive.
Whenever I try to mount the drive, `sudo dmesg` shows the following output:
```auto
[1369.382763] BTRFS: device label @ devid 1 transid 15560 /dev/mapper/luks-71971fba-64ae-4ae3-bfcc-5e45763220c4 (254:1) scanned by mount (8635)
[1369.383695] BTRFS info (device dm-1): first mount of filesystem 4c00058d-3dbb-4155-9223-f1255e998ec6
[1369.383714] BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm
[1369.383719] BTRFS info (device dm-1): using free-space-tree
[1369.559590] BTRFS info (device dm-1): start tree-log replay
[1369.559890] BTRFS error (device dm-1): bad tree block start, mirror 1 want 139771904 have 18010944275479632007
[1369.560183] BTRFS error (device dm-1): bad tree block start, mirror 2 want 139771904 have 12059563138185019958
[1369.560207] BTRFS warning (device dm-1): failed to read log tree
[1369.563843] BTRFS error (device dm-1): open_ctree failed
```
I ran `btrfs check` to see more details, and got this:
```auto
[nprevail@nixos:~]$ sudo btrfs check /dev/mapper/luks-71971fba-64ae-4ae3-bfcc-5e45763220c4
Opening filesystem to check...
checksum verify failed on 139771904 wanted 0xc29506c0 found 0x1bdac36f
checksum verify failed on 139771904 wanted 0x5dacb8de found 0xb7459c97
checksum verify failed on 139771904 wanted 0x5dacb8de found 0xb7459c97
bad tree block 139771904, bytenr mismatch, want=139771904, have=12059563138185019958
Couldn't setup log root tree
ERROR: cannot open file system
```
---
### Author:  [@EmergentMind](https://discourse.nixos.org/u/EmergentMind)
#### Post date: [August 15, 2025, 7:05pm UTC](https://discourse.nixos.org/t/solved-post-formerly-titled-as-btrfs-issue-open-ctree-failed-bad-tree-block-start-unmountable/59604/2 "2025-08-15T19:05:28Z")
Adding some info here for future readers because I ran into this problem on a LUKS encrypted drive and it seems that a bug may have been (re)introduced in somewhat recent kernel updates.
My error output was slightly different because I was forced to diagnose via an ISO environment so I’m also adding that here to improve search results for others.
```auto
BTRFS: Transaction aborted (error -17)
BTRFS: error (device dm-0 state A) in __btrfs_run_delayed_items:1168: errno=-17 Object already exists
BTRFS: error (device dm-0 state EA) in btrfs_replay_log:2100: errno=-17 Object already exists (Failed to recover ...
BTRFS error (device dm-0 state EA): open_ctree failed: -17
mount: /mnt: fsconfig() failed: File exists.
```
Like the OP, running `# brfs rescue zero-log /dev/foo` on the device worked for me.
Here is some related references that may be of additional assistance:
[https://lore.kernel.org/linux-btrfs/fce139db-4458-4788-bb97-c29acf6cb1df@cachyos.org/](https://lore.kernel.org/linux-btrfs/fce139db-4458-4788-bb97-c29acf6cb1df@cachyos.org/)
> **[Boot fails: btrfs errno=-17 Object already exists](https://discussion.fedoraproject.org/t/boot-fails-btrfs-errno-17-object-already-exists/90508/2)**
>
> You should be able to mount this file system using mount -o ro,rescue=nologreplay and it’s risk free. You can look around for some important files and even copy them out to a healthy alternative file system. The long term fix issudo btrfs rescue...