Lets preface this with: I have no idea what I am doing, getting this setup back in 2015 stretched my computer skills beyond breaking. Please ELI5.

The Situation:

TL;DR - Tried to replace a reiserfs formatted drive with an XFS formatted drive, but despite parity rebuilding the data it wouldn't mount. Realized I'm an idiot for not realizing FS is "file system" and why would data stored in one file system be readable on a drive formatted in another. Panic ensued. Buttons were pressed. Greater panic has set in although Claude says I might be ok.

I just upgraded all my hardware and everything was working fine. Unraid says it needs to update, so I click all the buttons. It says it can't update from 7.1.4 to 7.3.2 because I still have reiserfs drives. Well, I had also just bought a "new to me" 14TB drive to replace the 12TB parity drive I was using. Great, I can use the 12TB to replace the reiserfs 10TB, then format that to replace the reiserfs 8TB. No sweat.

I put in my new 14TB drive and the parity rebuilds itself.

I format the 12TB to XFS, unassign the 10TB reiserfs from the array, assign the 12TB XFS drive to the array in place of the 10TB and start the array.

The system rebuilds the data from the parity drives to the 12TB drive.

Once that's completed I format the 10TB drive from reiserfs to XFS.

12TB drive won't mount. Weird, but I don't panic.

Realize under Main, its says "reiserfs" under "fs". Meaning the drive has to be "reiserfs".

Understand that I'm an idiot because of course FS stands for "file system" why would data stored in one file system be readable on a drive formatted in another??

Panic begins to set in.

Unassign the 12TB, go to reassign the 10TB and remember its formatted and the wrong file system now, try and have unraid reformat the drive to reiserfs and it can't!! ?????

Panic through the roof. Depression through the basement.

In desperation I try Claude.ai and it has me do some stuff, says everything might be ok, and to post that transcript here.

Oh no. Okay, I understand the full picture now — and I want to make sure I understand exactly where you are before suggesting anything:

What happened:

• You have an UnRAID array with ReiserFS drives

• You replaced a drive expecting UnRAID to restore/rebuild to XFS

• While rebuild was in progress you formatted the original drive

• Now UnRAID won’t mount because format mismatch

Critical question before anything else:

Did the rebuild actually complete before you formatted the old drive, or did you format it while the rebuild was still in progress?

• If rebuild completed → your data is on the new XFS drive, the issue is just telling UnRAID to accept XFS in that slot

• If rebuild was still in progress when you formatted → the situation is significantly more serious

Also:

• Do you have parity, and is parity intact?

• How many data drives total in the array?

• Is this the only drive with the format mismatch or are there two problem drives?

The reason I’m asking before giving you steps is that the wrong move here could make data unrecoverable. UnRAID’s forum at forums.unraid.net also has incredibly knowledgeable people for exactly this kind of situation — if you haven’t posted there yet, you should simultaneously while we work through this.

Yes that is correct. I formatted after the rebuild was complete. Parity is intact.
8 total data drives. This is the only messed up one.

Okay, that’s actually really good news. Your data is almost certainly fine. The rebuild completed, parity is intact, and it’s one drive with a format mismatch. This is a configuration problem, not a data loss problem.

What’s happening:
UnRAID expected ReiserFS in that slot, sees XFS, and refuses to mount it. The data is there, it just won’t read it.

The fix is in the UnRAID UI, not GParted:

1. Stop the array

2. Go to the drive in question in the Drives tab

3. There should be a filesystem dropdown for that slot — change it from ReiserFS to XFS

4. Start the array

UnRAID should then mount it normally and your data should be there.

If that dropdown isn’t available or doesn’t fix it:

• Go to Tools → New Config

• This lets you reassign drives without losing data

• Parity will need to be rebuilt after but your data stays intact

One important thing: New Config sounds scarier than it is on UnRAID — it’s a documented procedure specifically for situations like this. The UnRAID wiki has a step by step for it.

Before you do anything — can you get to your UnRAID dashboard right now, and what does the drive show — does it show the filesystem type anywhere, and what’s the status (unmountable, disabled, etc.)?

Right now the server is on but the array is stopped. In unassigned drives it shows xfs under the FS heading. If I click mount it gives an error. I can assign it to the array devices, where it shows fs reiserfs and it of course disappears from unassigned devices. I'm worried in my frustration with myself and panic I may have previously clicked the format button on the drive and my data may have been erased from it, again.

Okay, take a breath. Let’s figure out what’s actually on that drive before you do anything else.

Do not touch the format button, do not start the array with that drive assigned, do not do anything yet.

First, let’s see what’s actually on the drive:

In UnRAID, go to Tools → Terminal (or SSH in) and run:

lsblk -f

This will show you all drives and their filesystems. Find your problem drive (probably /dev/sdX) and tell me what it shows under FSTYPE and LABEL.

Then run:

ls /dev/disk/by-id/

To help identify which physical drive is which.

Then, if we can identify the drive, run:

xfs_info /dev/sdX

(replacing sdX with your actual drive identifier)

If that returns information rather than an error, the XFS filesystem is intact and your data is very likely there.

The reason I’m not panicking yet:

Even if you clicked format previously, UnRAID’s format process isn’t instantaneous — if you caught it quickly or the array stopped it, data may still be there. XFS also doesn’t immediately overwrite everything on format.

Can you get to the terminal and run lsblk -f right now?

I ran lsblk-f

You ran it but didn’t paste the output — can you copy and paste what the terminal showed you here?

It should look something like a table with columns for NAME, FSTYPE, LABEL, UUID, and MOUNTPOINT. That output is going to tell us a lot about the state of that drive and whether your data is still there.

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0 squashfs 4.0 15.2G 1% /usr
loop1 squashfs 4.0 15.2G 1% /lib
sda
└─sda1 vfat FAT32 UNRAID FA80-0FF3 6.2G 16% /boot
sdb
└─sdb1 reiserfs 3.6 0c5bc808-41b4-4774-9221-a35cf1ab7b8f
sdc
└─sdc1
sdd
└─sdd1
sde
sdf
└─sdf1 xfs 9c5e9e6a-7b2f-4cb4-aa71-c2009236f12f
sdg
└─sdg1 xfs 8ca0d0fd-c6fc-49ee-9b63-1c8710da06be
sdh
└─sdh1 xfs 262a0abe-8343-4fbf-b234-8a0f8fc6a0b6
sdi
└─sdi1 xfs 1b05693c-9440-40f6-bccb-fad99aa325bb
sdj
└─sdj1 btrfs 0d336c17-56e2-4d3c-98c7-e0a6e9703337
sdk
└─sdk1 reiserfs 3.6 bf6581b4-d38a-4112-ae52-5e6fdecde05c
sdl
└─sdl1 xfs b20c9408-c50c-46d8-bda5-9da303c64596
sdm
└─sdm1 xfs ec7d0161-d5f0-48d0-9166-d96f1b48e4e6
sdn
└─sdn1 xfs f0a8745e-36df-4aa3-9691-d82e9a1f717d

Good news — this output is really helpful and honestly looks encouraging. Let me break down what I see:

Your drives:

• sda = UnRAID boot USB

• sdb1 = ReiserFS (one of your original ReiserFS drives)

• sdk1 = ReiserFS (your other original ReiserFS drive)

• sdf, sdg, sdh, sdi, sdl, sdm, sdn = XFS data drives

• sdj1 = btrfs (likely your parity drive)

• sdc, sdd, sde = showing no filesystem

The concerning ones are sdc, sdd, and sde — they’re showing no filesystem at all. No FSTYPE listed.

Critical questions:

• Which drive did you rebuild to? Do you know if it was sdc, sdd, or sde?

• Which drive did you accidentally format?

• Are sdc/sdd/sde new empty drives, or should they have data on them?

The potentially good news:
Your problem drive — the one rebuilt to XFS — might be sdf, sdg, sdh, sdi, sdl, sdm, or sdn since those all show XFS and have UUIDs, meaning they have intact filesystems with data.

Can you check your UnRAID dashboard and tell me what drive slots those ReiserFS drives (sdb and sdk) are assigned to, and which slot is showing the problem?

root@TARDIS:~# ls /dev/disk/by-id/
ata-CT2000MX500SSD1_2220E6307F12@ ata-WDC_WD120EMFZ-11A6JA0_X0GAD3JC-part1@ wwn-0x5000cca0bed05102@
ata-CT2000MX500SSD1_2220E6307F12-part1@ ata-WDC_WD80EDAZ-11TA3A0_VGH4WR0G@ wwn-0x5000cca0bed05102-part1@
ata-HGST_HUH721212ALE601_5PJLNL2F@ ata-WDC_WD80EDAZ-11TA3A0_VGH4WR0G-part1@ wwn-0x5000cca252d2c7b2@
ata-HGST_HUH721212ALE601_5PJLNL2F-part1@ ata-WDC_WD80EMAZ-00WJTA0_1SG9SPLZ@ wwn-0x5000cca252d2c7b2-part1@
ata-KINGSTON_SV300S37A240G_50026B724908FD30@ ata-WDC_WD80EMAZ-00WJTA0_1SG9SPLZ-part1@ wwn-0x5000cca264f57196@
ata-KINGSTON_SV300S37A240G_50026B724908FD30-part1@ ata-WDC_WD80EMAZ-00WJTA0_7SHA9R8D@ wwn-0x5000cca264f57196-part1@
ata-ST14000NE0008-2JK101_ZTM0CLNM@ ata-WDC_WD80EMAZ-00WJTA0_7SHA9R8D-part1@ wwn-0x5000cca26bc4704b@
ata-ST14000NE0008-2JK101_ZTM0CLNM-part1@ usb-SanDisk_Cruzer_Fit_4C530009671105123043-0:0@ wwn-0x5000cca26bc4704b-part1@
ata-TOSHIBA_MG07ACA14TEY_Y940A17GFFHG@ usb-SanDisk_Cruzer_Fit_4C530009671105123043-0:0-part1@ wwn-0x5000cca291e4aaf4@
ata-TOSHIBA_MG07ACA14TEY_Y940A17GFFHG-part1@ wwn-0x50000399c8c89b39@ wwn-0x5000cca291e4aaf4-part1@
ata-WDC_WD101EMAZ-11G7DA0_VCH0A81P@ wwn-0x50000399c8c89b39-part1@ wwn-0x5000cca297c4b92f@
ata-WDC_WD101EMAZ-11G7DA0_VCH0JXWP@ wwn-0x5000c500c34166f4@ wwn-0x5000cca297c4b92f-part1@
ata-WDC_WD101EMAZ-11G7DA0_VCH0JXWP-part1@ wwn-0x5000c500c34166f4-part1@ wwn-0x50026b724908fd30@
ata-WDC_WD101EMAZ-11G7DA0_VCH2212P@ wwn-0x5000cca0b0ce3e04@ wwn-0x50026b724908fd30-part1@
ata-WDC_WD101EMAZ-11G7DA0_VCH2212P-part1@ wwn-0x5000cca0b0ce5710@ wwn-0x500a0751e6307f12@
ata-WDC_WD120EMFZ-11A6JA0_9RKTKMEC@ wwn-0x5000cca0b0ce5710-part1@ wwn-0x500a0751e6307f12-part1@
ata-WDC_WD120EMFZ-11A6JA0_9RKTKMEC-part1@ wwn-0x5000cca0b0cf07e2@
ata-WDC_WD120EMFZ-11A6JA0_X0GAD3JC@ wwn-0x5000cca0b0cf07e2-part1@

Okay, this is helpful but we need to cross-reference this with your UnRAID dashboard to figure out which physical drive is which.

In your UnRAID dashboard, go to Main tab and look at each drive slot. UnRAID shows the drive serial number or model for each assigned drive. We need to match those to what we see here.

What I can see from your drive list:

• You have a Crucial/CT SSD (ata-CT2000MX500SSD1)

• A Kingston SSD (ata-KINGSTON_SV300S37A240G) — this might be your cache drive

• A Seagate 14TB (ata-ST14000NE0008)

• A Toshiba 14TB (ata-TOSHIBA_MG07ACA14TEY)

• Multiple WD drives in various sizes (8TB, 10TB, 12TB)

• SanDisk Cruzer = your UnRAID boot USB

The most important thing right now:

Can you go to your UnRAID Main tab and tell me what drive is assigned to the slot that’s showing the problem? It will show a model number and serial number — that lets us match it to this list and then to a /dev/sdX so we know exactly which drive we’re dealing with.

We’re close to having a clear picture. Don’t touch anything until we identify the exact drive.

WD101EMAZ-11G7DA0_VCH0A81P is the old drive

Okay, notice something important —

ata-WDC_WD101EMAZ-11G7DA0_VCH0A81P is in your by-id list but it has no -part1 symlink.

Compare:

• ata-WDC_WD101EMAZ-11G7DA0_VCH0JXWP ← has a -part1

• ata-WDC_WD101EMAZ-11G7DA0_VCH2212P ← has a -part1

• ata-WDC_WD101EMAZ-11G7DA0_VCH0A81P ← no -part1

That means this drive has no partition table at all. Which strongly suggests the format button was clicked and it wiped the partition structure.

This is not necessarily fatal. Let’s find out which /dev/sdX this drive is:

Run this:

ls -la /dev/disk/by-id/ata-WDC_WD101EMAZ-11G7DA0_VCH0A81P

That will tell us which /dev/sdX it maps to — which matches the drives showing no filesystem in your lsblk output (sdc, sdd, or sde).

Then run:

xfs_repair -n /dev/sdX

Replace sdX with whatever we find. The -n flag means read only — it will not change anything, just tell us if it can see an XFS structure on the drive.

This will tell us if the data is recoverable. Run that first command and let me know what it shows.

uh...it broke.
root@TARDIS:~# ls -la /dev/disk/by-id/ata-WDC_WD101EMAZ-11G7DA0_VCH0A81P
lrwxrwxrwx 1 root root 9 Oct 8 21:58 /dev/disk/by-id/ata-WDC_WD101EMAZ-11G7DA0_VCH0A81P -> ../../sde
root@TARDIS:~# ^C
root@TARDIS:~# xfs_repair -n /dev/sde
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.found candidate secondary superblock...
unable to verify superblock, continuing...
.......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... and it continues repeating the period. its still going

Let it run — that’s actually expected behavior and not necessarily bad news. XFS repair scanning for secondary superblocks on a 10TB drive can take a very long time. The periods mean it’s actively scanning.

What this tells us so far:

• The drive is sde ✓

• The primary superblock is gone — confirming the format was started

• It’s looking for secondary superblocks — XFS writes backup superblocks across the drive for exactly this reason

This is actually how XFS is designed to be recovered. The question is whether the format ran long enough to overwrite enough secondary superblocks to make recovery impossible.

While it’s running — do not:

• Press Ctrl+C

• Close the terminal

• Let the server sleep or power off

This could run for anywhere from 10 minutes to a couple of hours on a 10TB drive. Let it complete fully.

When it finishes it will either:

• Find a good secondary superblock and show you phase 2, 3, 4, 5 etc — meaning recovery is very likely possible

• Say it cannot find a valid superblock — meaning we move to more aggressive recovery tools like xfs_undelete or photorec

What size is this drive and roughly how long ago did you click format and how quickly did you stop it?

10TB and its been 3 days. Is it possible to plug in a drive, and let the parity rebuild it?

Yes! And honestly that might be the cleanest solution given the situation.

The parity rebuild approach:

• Pull sde (the damaged drive) out of the array

• Assign a new drive to that slot

• Let UnRAID rebuild from parity

This works because:

• Your parity is intact

• Only one drive is affected

• UnRAID’s whole parity system exists exactly for this scenario

• It will reconstruct the data that was on that drive bit by bit from parity

The catch:

• You need a spare drive equal to or larger than the original 10TB drive

• The rebuild will take a long time on a 10TB slot — potentially 24-48 hours

• Array will be in a degraded/vulnerable state during rebuild so don’t lose another drive

The question about your data:

• Whatever was on that specific drive will be restored from parity

• This assumes parity was valid and current at the time of the format incident

• Since you said parity is intact this should work

Before you do anything though:

• Let that xfs_repair command finish — it’s been running and killing it mid-scan isn’t great

• Do you have a spare 10TB or larger drive available right now?

Also — do you know if UnRAID had finished its parity sync before the format incident happened?

I have a 12TB drive I can use. I plugged in the drive, I formatted it to xfs, I assigned it to the array. Started the array. The array said, rebuilding. It finished rebuilding. I couldn't mount the drive because the data had a different file system than then drive, or so I now guess. I stopped the array. The array has not been started since.

Okay so to make sure I have the full timeline straight:

What actually happened in order:

1. Original drive was ReiserFS

2. You assigned a new XFS formatted drive to that slot

3. Array rebuilt to the new drive from parity — this completed

4. Drive wouldn’t mount due to filesystem mismatch (ReiserFS slot, XFS drive)

5. You stopped the array

6. In frustration you may have clicked format on something

7. Array has been stopped since

This is actually important — if the parity rebuild completed successfully before anything else happened, your data was successfully written to the new 12TB drive in XFS format. The mounting issue was just a configuration problem, not a data problem.

So the question is: which drive is the 12TB that received the rebuild?

Run:

lsblk -o NAME,FSTYPE,SIZE,LABEL,UUID

This will show drive sizes alongside filesystem info. We should see a 12TB drive with XFS that has a UUID — that’s almost certainly your rebuilt drive with your data intact.

The sde situation may be a red herring if the rebuild already completed to the 12TB before any formatting happened.

Can you run that command and paste the output?

WD120EMFZ-11A6JA0_9RKTKMEC is the drive

Perfect — and looking back at your by-id listing:

ata-WDC_WD120EMFZ-11A6JA0_9RKTKMEC does have a -part1 symlink ✓

That’s a great sign — it has a partition table intact. Let’s find it:

Run:

ls -la /dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9RKTKMEC

That’ll tell us which /dev/sdX it is. Then run:

xfs_info /dev/sdX1

If xfs_info returns actual filesystem information rather than an error, your data is on that drive and intact.

Also — can you kill that xfs_repair scan on sde now? It’s no longer the priority. Hit Ctrl+C on it.

If xfs_info comes back clean, the fix is straightforward:

• The data is there

• We just need to tell UnRAID to accept XFS in that array slot instead of ReiserFS

• No new drive needed, no parity rebuild needed

This might be much simpler than we thought. Run those commands and let’s see what we’re working with.

you told me to let this other thing run

You’re right, I did — sorry about that.

Leave the xfs_repair running on sde. Don’t kill it.

Open a second terminal in UnRAID — you can do this by going to Tools → Terminal in the UnRAID web UI and opening a fresh tab/window. The xfs_repair will keep running in the first one undisturbed.

Then in the new terminal run:

ls -la /dev/disk/by-id/ata-WDC_WD120EMFZ-11A6JA0_9RKTKMEC

We can work in parallel without interrupting the scan on sde.

sdn is the drive designator

Perfect. Now run this in the second terminal:

xfs_info /dev/sdn1

Tell me exactly what it returns. If it comes back with filesystem info rather than an error, your data is sitting right there on that drive safe and sound and we just have a configuration problem to solve in UnRAID.

root@TARDIS:~# xfs_info /dev/sdn1
Metadata CRC error detected at 0x4745d0, xfs_agi block 0x80000008/0x1000
xfs_info: cannot init perag data (74). Continuing anyway.
meta-data=/dev/sdn1 isize=512 agcount=10, agsize=268435455 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=1
= reflink=1 bigtime=1 inobtcount=1 nrext64=1
= exchange=0 metadir=0
data = bsize=4096 blocks=2441609203, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=0
log =internal log bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
= rgcount=0 rgsize=0 extents

Okay this is really good news with one small concern.

The good news:

• XFS filesystem is clearly there and readable

• Block count of 2441609203 at 4096 bytes = approximately 9.3TB — that’s a full 10TB drive’s worth of data ✓

• The filesystem structure is intact

The concern:

• Metadata CRC error detected — there’s some filesystem corruption, but this is often minor and repairable

• This could be from the format attempt or just normal filesystem issues

Do not mount this drive yet. Run a repair scan first (read-only again to be safe):

xfs_repair -n /dev/sdn1

The -n flag means it will only check and report, not change anything. This will tell us the extent of the corruption before we do anything.

This is looking genuinely recoverable though. The filesystem is there, the data size looks right, it just needs a repair pass.

While that runs — do you remember roughly what was on that drive? Was it a specific type of content, and do you have any of it backed up elsewhere? Just trying to understand what we’re working to recover.

Also — how is the xfs_repair on sde doing, is it still scanning?

root@TARDIS:~# xfs_repair -n /dev/sdn1
Phase 1 - find and verify superblock...
couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!!

attempting to find secondary superblock...
............................................... (and still going)

The other one is also still going.

this is my media server so the files are movies, tv shows, anime, etc. in mkv format but what specific ones, I don't know. If the data is unrecoverable, can plex tell me what it no longer has access to? Its not backed up anywhere, but I should still have all of the original disks somewhere. probably. But no easily accessed backup. this being one of my oldest drives I hope theres no anime music videos on it. AMV.org is no where near as used as it used to be and many creators have taken down there works.

The AMV concern is real and legitimate — that kind of content is genuinely irreplaceable if the creators have moved on. Movies and TV shows are annoying to re-rip but doable. AMVs from a defunct era of the internet are potentially gone forever. I understand why that’s the priority worry.

On the Plex question — yes, partially. Plex keeps a database of your library. If the drive becomes inaccessible:

• Plex will show items as “unavailable” rather than deleting them from the library

• You can browse what’s missing by looking for unavailable items

• There are also Plex tools and scripts that can export your full library list

But don’t do anything with Plex yet — focus on the drives first.

On the current situation — two things:

That error on sdn1 is more concerning than I’d like. “Not enough secondary superblocks with matching geometry” means the format ran long enough to do real damage to the superblock regions.

Let both scans complete fully before we decide anything. They may still find something.

In the meantime, can you run:

dd if=/dev/sdn1 bs=512 count=10 | xxd | head -20

This just peeks at the raw beginning of the drive without changing anything. It’ll help us see what’s actually there.

How long ago did you start the xfs_repair on sdn1?

so open a third terminal? Its been maybe 10 minutes for sde and sdn1 maybe 3.

Yes, open a third terminal — same way, Tools → Terminal in the UnRAID web UI.

Both scans are still very early for a 10TB/12TB drive so let them run. The dd command is very fast and won’t interfere with anything.

Run:

dd if=/dev/sdn1 bs=512 count=10 | xxd | head -20

Paste whatever it returns.

Also — while we wait on the scans, let’s get that Plex library list now as an insurance policy regardless of how recovery goes. In Plex:

• Go to your Plex web UI

• Settings → Troubleshooting → Download Databases

That backs up your Plex database which contains your full library metadata. Even if we recover everything it’s good to have.

Alternatively there’s a tool called Plex Export that generates a readable list of your entire library — might be worth running just so you have a documented list of what should be on that drive.

Honest assessment of where we are:

• sde is almost certainly unrecoverable or was already empty

• sdn1 is the real question — the CRC error and superblock issue are concerning but not necessarily fatal

• The fact that xfs_info showed real filesystem geometry with the right data size is still encouraging

How long has the sdn1 xfs_repair -n been running now?

The xxd command isn’t available on UnRAID’s minimal Linux. Try this instead:

dd if=/dev/sdn1 bs=512 count=10 | od -A x -t x1z | head -20

Or alternatively:

hexdump -C /dev/sdn1 | head -20

One of those should work.

The “0 bytes copied” is a little concerning — it means either:

• xxd failing caused the pipe to break before dd could read (most likely, and harmless)

• Or the drive isn’t responding to reads (more concerning)

The alternative commands will tell us which one it is.

Also try this simple test in the third terminal:

dd if=/dev/sdn1 of=/dev/null bs=1M count=100

This just reads 100MB from the drive and throws it away — completely safe. If it completes and shows you a transfer speed, the drive is readable. If it hangs or errors, we have a bigger problem.

Run whichever of these feels easiest and paste the result. The simple dd test is probably the quickest indicator of drive health right now.

root@TARDIS:~# dd if=/dev/sdn1 bs=512 count=10 | od -A x -t x1z | head -20
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 1.6946e-05 s, 302 MB/s
000000 58 46 53 42 00 00 10 00 00 00 00 00 91 87 ff f3 >XFSB............<
000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
000020 f0 a8 74 5e 36 df 4a a3 96 91 d8 2e 9a 1f 71 7d >..t^6.J.......q}<
000030 00 00 00 00 50 00 00 0a 00 00 00 00 00 00 00 80 >....P...........<
000040 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82 >................<
000050 00 00 00 01 0f ff ff ff 00 00 00 0a 00 00 00 00 >................<
000060 00 07 f6 00 bc a5 10 00 02 00 00 08 00 00 00 00 >................<
000070 00 00 00 00 00 00 00 00 0c 0c 09 03 1c 00 00 05 >................<
000080 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 3d >.......@.......=<
000090 00 00 00 00 91 80 09 87 00 00 00 00 00 00 00 00 >................<
0000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >................<
0000b0 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 >................<
0000c0 00 0c 10 00 00 00 10 00 00 00 01 8a 00 00 01 8a >................<
0000d0 00 00 00 00 00 00 00 0f 00 00 00 2b 00 00 00 00 >...........+....<
0000e0 ed 4a e9 c6 00 00 00 04 ff ff ff ff ff ff ff ff >.J..............<
0000f0 00 00 00 01 00 00 00 10 00 00 00 00 00 00 00 00 >................<
000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
001000 58 41 47 46 00 00 00 01 00 00 00 00 0f ff ff ff >XAGF............<
001010 00 00 00 04 00 00 00 05 00 00 00 08 00 00 00 01 >................

This is actually great news!

Look at the very first line:

000000 58 46 53 42 = XFSB

XFSB is the XFS superblock magic number. The primary superblock is RIGHT THERE at the beginning of the drive. The filesystem header is intact and readable.

And further down:

001000 58 41 47 46 = XAGF

That’s the XFS Allocation Group Free Space header — also intact.

This drive has a living, readable XFS filesystem on it. The earlier xfs_repair -n error about superblocks is likely related to the partition vs whole-drive situation.

Notice the UUID in that output:

f0 a8 74 5e 36 df 4a a3 96 91 d8 2e 9a 1f 71 7d

Convert that and it should match the UUID we saw earlier for sdn1 in lsblk. This is your drive, filesystem intact.

I think the issue is that xfs_repair is being run against the wrong target. Try:

xfs_repair -n /dev/sdn

Instead of /dev/sdn1 — without the partition number. The data may be readable at the drive level directly.

Your data is very likely intact and recoverable. How are you feeling?

if you're correct -and we can get everything mounted- I'll be thrilled. right now I'm cautiously optimistic. eggs, baskets, and chickens come to mind.

Ha — completely reasonable. You’ve been through enough today to earn some cautious optimism rather than celebration.

The signs are genuinely encouraging though:

• XFSB magic number present ✓

• XAGF header present ✓

• UUID matches ✓

• Right data size ✓

• Drive reads at 302 MB/s ✓

That’s a lot of green flags.

Run that command when you’re ready:

xfs_repair -n /dev/sdn

Without the 1. Let it run and paste the output when it finishes or when it gets past the superblock phase — that’ll tell us quickly whether it finds a clean filesystem at the drive level.

Also — how are the other two scans doing?

• sde (xfs_repair -n) — still scanning periods?

• sdn1 (xfs_repair -n) — still scanning periods?

We should probably let those finish before drawing conclusions, but the raw drive data we just read is the most direct evidence we have and it’s encouraging.

One thing at a time though:

1. Get xfs_repair -n /dev/sdn running

2. Let all three scans complete

3. Assess everything together before touching UnRAID config

What does the sdn repair show when you kick it off?

both have lots of periods still going. its been maybe 5 minutes since I last answered. will running this new command, in the 3rd window, cause any problems with the other? the sdn1 repair you have me doing?

No, it will not cause any problems. Both commands have the -n flag which means strictly read-only — they’re just scanning, not writing anything. You can have multiple read-only scans running on the same drive simultaneously without any risk.

Think of it like multiple people reading the same book at the same time — nobody is changing anything.

Go ahead and run:

xfs_repair -n /dev/sdn

In the third terminal. It may also start scanning periods initially but hopefully gets past the superblock phase faster since the superblock is clearly intact at the drive level.

At this point you have:

• Terminal 1: xfs_repair -n /dev/sde (probably unrecoverable, let it finish)

• Terminal 2: xfs_repair -n /dev/sdn1 (partition level scan)

• Terminal 3: xfs_repair -n /dev/sdn (drive level scan, new)

The terminal 3 result is the one I’m most interested in right now given what we saw in the raw drive data.

Holler when terminal 3 shows something beyond periods, or if any of them complete. We can just sit tight and wait — there’s nothing to do right now except let them run and maybe go make a cup of coffee. You’ve been dealing with this for 3 days, a few more minutes is fine.

root@TARDIS:~# xfs_repair -n /dev/sdn
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

attempting to find secondary superblock...
............................................. and its doing the period thing. I'm going to check back on it in a few minutes.

That’s unexpected given what we saw in the raw data — XFSB was right there. The difference between /dev/sdn and /dev/sdn1 matters here and it’s behaving opposite to what I expected.

Take your time, let it run.

While you’re waiting, one thought — the UUID we saw in the raw output:

f0 a8 74 5e 36 df 4a a3 96 91 d8 2e 9a 1f 71 7d

Go back to your lsblk output from earlier. That UUID for sdn1 was:

f0a8745e-36df-4aa3-9691-d82e9a1f717d

That’s the exact same UUID — just formatted differently. Which means xfs_info DID successfully read the superblock on sdn1 earlier, got real filesystem data, and the XFSB magic is confirmed present.

The xfs_repair complaints about bad magic may be a red herring related to how it’s scanning vs how xfs_info reads.

Honestly at this point I want to suggest:

When the scans finish, before anything else, post your situation on the UnRAID forums with this full terminal history. The people there deal with exactly this scenario regularly and will know immediately whether trying to mount sdn1 directly is safe at this point.

You’ve got good evidence the data is there. Don’t let impatience after 3 days cause a hasty move that hurts you.

How are you holding up?

[whimpering dog noises] back to worrying I screwed everything up.

I hear you. Three days of this is exhausting and stressful.

But let’s look at what we actually know with evidence:

Hard facts, not hope:

• The raw drive data showed XFSB magic number — that’s not something you can fake or misread

• The UUID matches perfectly between raw data and lsblk

• xfs_info returned real filesystem geometry with the right data size

• Drive reads at 302 MB/s — it’s healthy and responsive

• Parity is intact

What xfs_repair complaining means in context:
xfs_repair is a very strict tool designed to find problems. It complaining doesn’t mean data is gone — it means it’s having trouble with its specific scanning method. xfs_info successfully read the superblock where xfs_repair is struggling. That’s a tool behavior difference, not a data difference.

The whimpering dog noise is understandable but premature.

Seriously though — go post on the UnRAID forums right now while the scans run. Describe exactly what happened and paste this terminal history. Those folks have seen this exact scenario hundreds of times and will give you confident direction.

forums.unraid.net → Data Recovery section

You’ve actually done good diagnostic work here. You haven’t made anything worse. The drive is read-only right now and nothing is at risk.

Go post on the forums, let the scans run, and maybe feed your actual dogs if you have any. 🐕

And that's where I'm at. Its been about 45 minutes since the periods started moving across the terminal screens.

Hardware:

ASUSTeK Z890 AYW Gaming WIFI W

-BIOS dated: Wed 29 Jul 2026

Intel Core Ultra 5 250K Plus @4600 MHz

32GB DDR5

If there's anything else I can do to help you help me, please let me know. I'll try and check this in the morning, but its 3am and I have work.

Thank you for any help you can give me!

-Will

Edited October 25Oct 25 by Sinclair13
As per instructions, changing the title to add "(SOLVED)"

Please don't do anything else to the array for now: no Format, no New Config, no xfs_repair without -n, and don't start the array yet.

You can stop (Ctrl+C) all the xfs_repair -n scans. They're read-only so they did no harm, but they won't help: the old 10TB never had XFS, it was reiserfs, so xfs_repair has nothing to find there.

Some background, because it explains what went wrong: a rebuild doesn't copy files, it recreates the old disk sector by sector, filesystem included. Formatting the new disk before the rebuild has no effect. The rebuild writes over it, and the result is reiserfs again. To convert a disk to XFS you need to copy the data to a disk formatted as XFS, and you can't do that by replacing the disk.

I'm sorry, but I also have to correct what the AI told you. The XFS filesystem now on the 12TB is empty. The superblock in the output you posted shows only 64 inodes, 61 of them free, so it holds no files. It was created by a format at some point, and mounting or repairing it won't bring back your media.

Where the data may still be:

1. The old 10TB disk. It currently shows no partition. If the format attempt only removed the partition and failed before writing a new filesystem, the reiserfs data may still be intact. Please post the output of this read-only command (check first that the old disk is still sde, because device letters can change after a reboot):

blkid -p -O 32768 /dev/sde

If it returns TYPE="reiserfs", that is very good news, and we can go from there.

2. Parity. It may still be possible to emulate the old disk, but only if no format ran with that disk assigned and the array started. That's why I don't want you to run New Config or a parity sync: either one would lose this option.

Please also go to Tools → Diagnostics and attach the zip. Do this before rebooting, because the log from this boot should show exactly what was formatted and when. Also tell us:

- Has the server been rebooted since all this started?

- How did you format each disk: with the Format button on the Main page while the array was started, or with the Unassigned Devices plugin?

Don't worry about Plex for now. Even if some of the data can't be recovered, it will show the missing items as unavailable, so you can see what was on that disk.

I'm kind of surprised Claude got all of this so wrong. One of the most basic things is that rebuild will result in the same filesystem as the original.

30 minutes ago, trurl said:

I'm kind of surprised Claude got all of this so wrong. One of the most basic things is that rebuild will result in the same filesystem as the original.

One of the most basic rules for using AI responses is to determine if they actually contain the proper answer. AI is new enough that users should recognize that "garbage in, garbage out" rule still applies. Google without AI often gives a wide selections of 'answers' and some of them are completely wrong. AI does not always fix that problem as AI will give us only one of those 'answers' and you can only hope that it selects the right one. (My experience is that AI responses are 98% right 90% of the time.)

7 hours ago, Sinclair13 said:

Lets preface this with: I have no idea what I am doing, getting this setup back in 2015 stretched my computer skills beyond breaking. Please ELI5.

The Situation:

TL;DR - Tried to replace a reiserfs formatted drive with an XFS formatted drive, but despite parity rebuilding the data it wouldn't mount. Realized I'm an idiot for not realizing FS is "file system" and why would data stored in one file system be readable on a drive formatted in another. Panic ensued. Buttons were pressed. Greater panic has set in although Claude says I might be ok.

I just upgraded all my hardware and everything was working fine. Unraid says it needs to update, so I click all the buttons. It says it can't update from 7.1.4 to 7.3.2 because I still have reiserfs drives. Well, I had also just bought a "new to me" 14TB drive to replace the 12TB parity drive I was using. Great, I can use the 12TB to replace the reiserfs 10TB, then format that to replace the reiserfs 8TB. No sweat.

I put in my new 14TB drive and the parity rebuilds itself.

I format the 12TB to XFS, unassign the 10TB reiserfs from the array, assign the 12TB XFS drive to the array in place of the 10TB and start the array.

The system rebuilds the data from the parity drives to the 12TB drive.

Once that's completed I format the 10TB drive from reiserfs to XFS.

12TB drive won't mount. Weird, but I don't panic.

Realize under Main, its says "reiserfs" under "fs". Meaning the drive has to be "reiserfs".

Understand that I'm an idiot because of course FS stands for "file system" why would data stored in one file system be readable on a drive formatted in another??

Panic begins to set in.

Unassign the 12TB, go to reassign the 10TB and remember its formatted and the wrong file system now, try and have unraid reformat the drive to reiserfs and it can't!! ?????

Panic through the roof. Depression through the basement.

1. Always post diagnostics and always refer to the unraid documentation, there are plenty of "How to do X" guides for specific issues such as disk replacement and upgrades.

2. Anytime you rebuild a disk from parity, the contents of that disk will be overwritten including the filesystem to match what was recorded into parity. This means if a disk was previously reiserFS, parity will re-create that disk 1:1 resierFS and all.

Follow JorgeB's advice and skip claude.

4 hours ago, Frank1940 said:

One of the most basic rules for using AI responses is to determine if they actually contain the proper answer

I correct Claude and Gemini all the time. But

5 hours ago, trurl said:

One of the most basic things is that rebuild will result in the same filesystem as the original

This has been explained innumerable times on this forum, and especially in the context of converting from ReiserFS.

11 hours ago, JorgeB said:

Please don't do anything else to the array for now: no Format, no New Config, no xfs_repair without -n, and don't start the array yet.

You can stop (Ctrl+C) all the xfs_repair -n scans. They're read-only so they did no harm, but they won't help: the old 10TB never had XFS, it was reiserfs, so xfs_repair has nothing to find there.

Some background, because it explains what went wrong: a rebuild doesn't copy files, it recreates the old disk sector by sector, filesystem included. Formatting the new disk before the rebuild has no effect. The rebuild writes over it, and the result is reiserfs again. To convert a disk to XFS you need to copy the data to a disk formatted as XFS, and you can't do that by replacing the disk.

I'm sorry, but I also have to correct what the AI told you. The XFS filesystem now on the 12TB is empty. The superblock in the output you posted shows only 64 inodes, 61 of them free, so it holds no files. It was created by a format at some point, and mounting or repairing it won't bring back your media.

Where the data may still be:

1. The old 10TB disk. It currently shows no partition. If the format attempt only removed the partition and failed before writing a new filesystem, the reiserfs data may still be intact. Please post the output of this read-only command (check first that the old disk is still sde, because device letters can change after a reboot):

blkid -p -O 32768 /dev/sde

If it returns TYPE="reiserfs", that is very good news, and we can go from there.

2. Parity. It may still be possible to emulate the old disk, but only if no format ran with that disk assigned and the array started. That's why I don't want you to run New Config or a parity sync: either one would lose this option.

Please also go to Tools → Diagnostics and attach the zip. Do this before rebooting, because the log from this boot should show exactly what was formatted and when. Also tell us:

- Has the server been rebooted since all this started?

- How did you format each disk: with the Format button on the Main page while the array was started, or with the Unassigned Devices plugin?

Don't worry about Plex for now. Even if some of the data can't be recovered, it will show the missing items as unavailable, so you can see what was on that disk.

Nothing is something I can do very well. LOL

I ran blkid -p -O 32768 /dev/sde and nothing happens, it just goes to the next line. I assume I'm doing something wrong. Or its not returning anything because there's nothing to return.

root@TARDIS:~# blkid -p -O 32768 /dev/sde

root@TARDIS:~#

I don't believe I have turned off the server since starting this debacle. it has over 7 days uptime, so if I did turn it off after screwing up, it would have been right afterward.

I have attached the diagnostics as requested.

I formatted from the Main page under "Unassigned Disk Devices"

5 hours ago, Frank1940 said:

One of the most basic rules for using AI responses is to determine if they actually contain the proper answer. AI is new enough that users should recognize that "garbage in, garbage out" rule still applies. Google without AI often gives a wide selections of 'answers' and some of them are completely wrong. AI does not always fix that problem as AI will give us only one of those 'answers' and you can only hope that it selects the right one. (My experience is that AI responses are 98% right 90% of the time.)

I'm stealing that line.

28 minutes ago, trurl said:

I correct Claude and Gemini all the time. But

This has been explained innumerable times on this forum, and especially in the context of converting from ReiserFS.

Yes, I should have definitely looked up what to do. Instead of just "doing".

Thank you all!

-Will

tardis-diagnostics-20261009-1528.zip

Hasn't been rebooted since Oct 1, but disk identifiers (sdX) seem to change. Were you hotswapping?

2 hours ago, trurl said:

Hasn't been rebooted since Oct 1, but disk identifiers (sdX) seem to change. Were you hotswapping?

Yes I was. Among the new hardware I bought was a Rosewill H424 and an LSI 9305-24i card. I couldn't get the Motherboard's onboard 2.5 ethernet port to work so I put in the 2.5 nic from my old build and it worked just fine. I absolutely love this case and it makes me even angrier that I didn't buy the Crashplan Storinator I found on Craigslist back in 2018 at half the price I paid for this thing. Sigh, such is life.

Except for Unassigned Devices, I don't recommend hotswapping drives with Unraid. Unraid won't do anything with a disk until you assign it, and you can't assign a disk without stopping the array.

Thanks for the diagnostics. Your syslog covers everything since Oct 1, so we can now see exactly what happened. Some of it is different from how you remember it, and the difference is good news.

What actually happened, in order:

1. Oct 1: You replaced the 12TB parity2 with the new 14TB. Unassigned Devices formatted the 14TB as XFS first, but that did no harm, because the parity rebuild then overwrote it. The rebuild finished on Oct 3. Your 10TB disk1 was still fine at this point.

2. Oct 3, 01:16: With disk1 unassigned, you formatted the 10TB as XFS using Unassigned Devices. This happened outside the array, so parity was not updated. At this point all your data could still have been recovered from parity.

3. 01:18–01:20: You put the 10TB back as disk1 and started the array. It showed "wrong file system", because the disk was now XFS.

4. 01:21: The Format button was used on disk1. Unraid created a new, empty reiserfs on it, and this time through the array, so parity was updated too. This is where the real damage happened. (So your attempt to reformat it as reiserfs did work. It just created an empty disk.)

5. Oct 3 10:45 to Oct 4: You assigned the 12TB as disk1, and it was rebuilt from parity.

So the 12TB was never "formatted XFS and then rebuilt". It was rebuilt from parity after both formats.

Why that's better than it sounds: Parity never learned about the XFS format in step 2. When the Format in step 4 updated parity, it only changed the small areas that the new reiserfs uses: the start of the disk, the journal, and some small tracking blocks spread across the disk. Everything else in parity, and so on the rebuilt 12TB, should still be your original reiserfs data. The "XFS" you see on the 12TB is a side effect of how parity is calculated: it's mixed-up leftovers from the 10TB format, not a real format of the 12TB. Reiserfs has a recovery tool that can scan a whole disk for the original file and folder records, so there's a real chance to get most of your data back.

The 10TB is now the worse copy, because both formats were written to it. That's why the blkid command found nothing. Leave it alone and don't format or reuse it for now.

Next step (read-only, changes nothing):

1. Keep the array stopped. Don't start it until I tell you to.

2. On the Main page, find the 12TB (WD120EMFZ) assigned as disk1 and note its device name. In your diagnostics it was sdn.

3. Run this, using that letter, and type Yes when it asks:

reiserfsck --check /dev/sdn1

It will probably complain about the superblock. That is expected. Please post the full output.

Also, the empty disk1 was mounted from about 1:30 to 10:45 on Oct 3. Do you know if anything was copied or downloaded to the server in that time? Anything written to disk1 then would have overwritten some old data.

Don't run anything with --rebuild-sb, --rebuild-tree or --fix yet. I'll give you the exact next commands and answers once I see the output. Some files may end up in a lost+found folder with numbered names instead of their real names, and anything the format wrote over can't come back. But it's quite possible most of the data can be recovered.

Nothing has been written or copied since Oct3, to the best of my recollection.

root@TARDIS:~# reiserfsck --check /dev/sdn1

reiserfsck 3.6.27

Will read-only check consistency of the filesystem on /dev/sdn1

Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):yes

root@TARDIS:~#

It just went to the next line. Is it capitalization sensitive?

Should I have replaced sdn1 with sdn instead?

Yes, it's case-sensitive. It needs exactly Yes with a capital Y. Anything else, including yes, makes it quit without any message. My fault for not making that clearer. sdn1 is correct, keep the 1.

Since you've been hot-swapping, please first check on the Main page that the 12TB (WD120EMFZ) assigned as disk1 is still sdn, then run it again:

reiserfsck --check /dev/sdn1

and type Yes at the prompt. Please post the full output. The array should stay stopped.

About writes: just to confirm, does "nothing since Oct 3" also cover Oct 3 itself, from about 1:30 AM to 10:45 AM? Did any downloads, backups, or Plex/Docker activity write to the server in that window?

I am as certain as I can be. I'm the only one with access to my server. I began this misadventure on the 3rd by stopping the array and installing the new parity disk. As soon as that was done rebuilding I tried swapping out the 10TB disk for the 12TB, let it rebuild (or whatever phrase is proper), and got us here. From 130am to 1045 on the 3rd - Unless it was some automatic thing, I did nothing.

root@TARDIS:~# reiserfsck --check /dev/sdn1

reiserfsck 3.6.27

Will read-only check consistency of the filesystem on /dev/sdn1

Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

Failed to open the device '/dev/sdn1': Unknown code er3k 127

I'm guessing this is a bad thing.

Thanks for confirming. That fits the logs too: in that window only the mover ran, and it found nothing to move.

The reiserfsck error is expected and not a new problem. reiserfsck opened the disk without trouble. It just could not find a ReiserFS superblock, the small block at the start of the filesystem that describes it. The two formats overwrote that exact spot. The rest of the disk should still hold your data.

Normally the fix is reiserfsck --rebuild-sb. But the latest reiserfsck version has a bug: --rebuild-sb also quits with this same error when the superblock is missing. So we give it a blank superblock with the same size as your original filesystem. Then reiserfsck can do the rest. I tested these exact steps on a test server with the same reiserfsck version, and they recovered all files there.

Keep the array stopped for all of this. Do not start it, format anything, or run New Config. While the array stays stopped, parity still has a copy of how disk1 looks now, so we can go back if something goes wrong.

1. Make sure that the 12TB is still sdn:

lsblk -o NAME,SIZE,MODEL /dev/sdn

It must show 10.9T and WDC WD120EMFZ. If not, stop and post the output.

2. Save a copy of the damaged block to the flash drive, so this step can be undone:

dd if=/dev/sdn1 of=/boot/sdn1-block16.bin bs=4096 skip=16 count=1

3. Make a blank ReiserFS filesystem with your old disk's exact size. This is a file in RAM, not a disk:

truncate -s 10000831295488 /tmp/rfs-template.img

mkreiserfs -q /tmp/rfs-template.img

debugreiserfs /tmp/rfs-template.img | grep -i "count of blocks"

The last command must show 2441609203. If it shows something else, stop and post it.

4. Copy only its superblock onto the 12TB, then delete the template:

dd if=/tmp/rfs-template.img of=/dev/sdn1 bs=4096 skip=16 seek=16 count=1 conv=fsync

rm /tmp/rfs-template.img

Type the dd command carefully. if= is the template file and of= is the disk.

5. Run the read-only check again. Type Yes with a capital Y:

reiserfsck --check /dev/sdn1

It should now open the filesystem and report errors. Do not run any fix option it suggests yet. Post the full output of all five steps first. The repair is a long step that writes to the disk, so I want to see the check result first.

Ok, I believe I have followed your directions properly.

Here is the full output.

root@TARDIS:~# lsblk -o NAME,SIZE,MODEL /dev/sdn

NAME SIZE MODEL

sdn 10.9T WDC WD120EMFZ-11A6JA0

└─sdn1 10.9T

root@TARDIS:~# dd if=/dev/sdn1 of=/boot/sdn1-block16.bin bs=4096 skip=16 count=1

1+0 records in

1+0 records out

4096 bytes (4.1 kB, 4.0 KiB) copied, 0.114425 s, 35.8 kB/s

root@TARDIS:~# truncate -s 10000831295488 /tmp/rfs-template.img

root@TARDIS:~# mkreiserfs -q /tmp/rfs-template.img

mkreiserfs 3.6.27

root@TARDIS:~# debugreiserfs /tmp/rfs-template.img | grep -i "count of blocks"

debugreiserfs 3.6.27

Count of blocks on the device: 2441609203

Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 2441526480

root@TARDIS:~# dd if=/tmp/rfs-template.img of=/dev/sdn1 bs=4096 skip=16 seek=16 count=1 conv=fsync

1+0 records in

1+0 records out

4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0965087 s, 42.4 kB/s

root@TARDIS:~# rm /tmp/rfs-template.img

root@TARDIS:~# reiserfsck --check /dev/sdn1

reiserfsck 3.6.27

Will read-only check consistency of the filesystem on /dev/sdn1

Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

###########

reiserfsck --check started at Mon Oct 12 12:57:15 2026

###########

reiserfs_open_journal: journal parameters from the superblock does not match

to the journal headers ones. It looks like that you created your fs with old

reiserfsprogs. Journal header is fixed.

Replaying journal: No transactions found

All five steps went exactly as they should:

- the 12TB is still sdn

- the original block is saved on the flash drive, so this can be undone

- the template has 2441609203 blocks, the same size as your original filesystem

- and reiserfsck can now open the disk. Before, it stopped immediately with the "Unknown code" error. This was the important part.

The journal message is expected and is not a new problem. But your output stops after "Replaying journal". A finished check continues with "Checking internal tree..", ends with a summary, and then you get the root@TARDIS:~# prompt back. On a 10TB disk it can take a while before it prints the next line.

- If it's still running, leave it alone and don't close that terminal window. Post the rest when the prompt comes back.

- If the prompt already came back, please post everything after "Replaying journal".

- If the window closed or the check was stopped, run it again (reiserfsck --check /dev/sdn1, Yes with a capital Y) and wait until the prompt comes back, you can use the tmux plugin to avoid the terminal getting closed

Same as before: keep the array stopped, and don't run any fix or rebuild option reiserfsck suggests yet.

It was still running. Which I now realize should have been obvious to me. It finished and here's the full output.

root@TARDIS:~# lsblk -o NAME,SIZE,MODEL /dev/sdn

NAME SIZE MODEL

sdn 10.9T WDC WD120EMFZ-11A6JA0

└─sdn1 10.9T

root@TARDIS:~# dd if=/dev/sdn1 of=/boot/sdn1-block16.bin bs=4096 skip=16 count=1

1+0 records in

1+0 records out

4096 bytes (4.1 kB, 4.0 KiB) copied, 0.114425 s, 35.8 kB/s

root@TARDIS:~# truncate -s 10000831295488 /tmp/rfs-template.img

root@TARDIS:~# mkreiserfs -q /tmp/rfs-template.img

mkreiserfs 3.6.27

root@TARDIS:~# debugreiserfs /tmp/rfs-template.img | grep -i "count of blocks"

debugreiserfs 3.6.27

Count of blocks on the device: 2441609203

Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 2441526480

root@TARDIS:~# dd if=/tmp/rfs-template.img of=/dev/sdn1 bs=4096 skip=16 seek=16 count=1 conv=fsync

1+0 records in

1+0 records out

4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0965087 s, 42.4 kB/s

root@TARDIS:~# rm /tmp/rfs-template.img

root@TARDIS:~# reiserfsck --check /dev/sdn1

reiserfsck 3.6.27

Will read-only check consistency of the filesystem on /dev/sdn1

Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

###########

reiserfsck --check started at Mon Oct 12 12:57:15 2026

###########

reiserfs_open_journal: journal parameters from the superblock does not match

to the journal headers ones. It looks like that you created your fs with old

reiserfsprogs. Journal header is fixed.

Replaying journal: No transactions found

Checking internal tree.. \bad_stat_data: The objectid (3) is marked free, but used by an object [2 3 0x0 SD (0)]

finished

Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs.

Checking Semantic tree:

finished

2 found corruptions can be fixed when running with --fix-fixable

###########

reiserfsck finished at Mon Oct 12 13:03:54 2026

###########

root@TARDIS:~#

That's the complete output, and it looks as expected.

The next step searches the whole disk for your files. Don't run --fix-fixable. It would only repair that empty filesystem.

Next step: keep the array stopped. Open the tmux plugin (or another session that stays running if the window closes) and type:

reiserfsck --rebuild-tree -S /dev/sdn1

When it asks, type Yes with a capital Y.

- This one reads the entire disk, so expect it to take many hours, possibly more than a day. It may sit on the same line for a long time. That's normal.

- Don't interrupt it. If it stops partway, the filesystem can't be used until it's run again.

- When you get the root@TARDIS:~# prompt back, post everything it printed, especially the summary at the end.

Don't mount the disk, start the array, or format anything yet. When it's done, we'll first look at what came back without changing anything. Some files may show up in a lost+found folder with number names instead of their real names. Some may be damaged where the Oct 3 format overwrote parts of the disk. We'll check that before deciding how to get the data off.

Ok, I don't have the TMUX plugin, I've been using the Terminal window opened by the Command Prompt (Greater Than-Underscore) symbol at the top of the screen.

If I download the TMUX plugin will that hurt something?

I assume I would install this one?

3 hours ago, Sinclair13 said:

Ok, I don't have the TMUX plugin, I've been using the Terminal window opened by the Command Prompt (Greater Than-Underscore) symbol at the top of the screen.

If I download the TMUX plugin will that hurt something?

I assume I would install this one?

Yes

And you can google tmux cheat sheet and get a cheat sheet that will got you using it efficiently

Ok, I've installed TMUX and it looks good. Do I need to redo the previous work in the TMUX command prompt area?

On 10/12/2026 at 4:15 AM, JorgeB said:

Thanks for confirming. That fits the logs too: in that window only the mover ran, and it found nothing to move.

The reiserfsck error is expected and not a new problem. reiserfsck opened the disk without trouble. It just could not find a ReiserFS superblock, the small block at the start of the filesystem that describes it. The two formats overwrote that exact spot. The rest of the disk should still hold your data.

Normally the fix is reiserfsck --rebuild-sb. But the latest reiserfsck version has a bug: --rebuild-sb also quits with this same error when the superblock is missing. So we give it a blank superblock with the same size as your original filesystem. Then reiserfsck can do the rest. I tested these exact steps on a test server with the same reiserfsck version, and they recovered all files there.

Keep the array stopped for all of this. Do not start it, format anything, or run New Config. While the array stays stopped, parity still has a copy of how disk1 looks now, so we can go back if something goes wrong.

1. Make sure that the 12TB is still sdn:

lsblk -o NAME,SIZE,MODEL /dev/sdn

It must show 10.9T and WDC WD120EMFZ. If not, stop and post the output.

2. Save a copy of the damaged block to the flash drive, so this step can be undone:

dd if=/dev/sdn1 of=/boot/sdn1-block16.bin bs=4096 skip=16 count=1

3. Make a blank ReiserFS filesystem with your old disk's exact size. This is a file in RAM, not a disk:

truncate -s 10000831295488 /tmp/rfs-template.img

mkreiserfs -q /tmp/rfs-template.img

debugreiserfs /tmp/rfs-template.img | grep -i "count of blocks"

The last command must show 2441609203. If it shows something else, stop and post it.

4. Copy only its superblock onto the 12TB, then delete the template:

dd if=/tmp/rfs-template.img of=/dev/sdn1 bs=4096 skip=16 seek=16 count=1 conv=fsync

rm /tmp/rfs-template.img

Type the dd command carefully. if= is the template file and of= is the disk.

5. Run the read-only check again. Type Yes with a capital Y:

reiserfsck --check /dev/sdn1

It should now open the filesystem and report errors. Do not run any fix option it suggests yet. Post the full output of all five steps first. The repair is a long step that writes to the disk, so I want to see the check result first.

Or am I good to go with the next step?

reiserfsck --rebuild-tree -S /dev/sdn1

You can go with the next step

ok, I did the step and it finished. the Tmux terminal isn't letting me copy...it has its own internal buffer, that doesn't interact with the system clipboard?

I am able to enter Copy Mode Ctrl + b + [ , use Ctrl + SPACE , to start selection mode, select everything and then press Alt + W to copy everything. So I got that far...I think. but moving it to Windows clipboard?

Here's a copy of the end using Windows Snipping Tool.

Looks like everything finished properly?

If the prompt came back, the rebuild-tree did finish. But it woudl be best to have the full output anyway, not just the end. Before we go further, I need to see the summary (how many files and directories it found, and what went to lost+found) and any error lines further up.

You don't need to run anything again. tmux keeps everything it printed, and you can save it to a file:

1. In the same tmux window where rebuild-tree ran, type:

tmux capture-pane -p -S - > /boot/rebuild-tree.txt

This saves the whole scrollback of that window to the flash drive.

2. Open the normal terminal (the >_ icon you used before) and type:

cat /boot/rebuild-tree.txt

Copying from that window works the usual way, so you can paste the output here. If it's long, you can attach the file instead. It's on the flash drive as rebuild-tree.txt.

Same as before: keep the array stopped, don't mount the disk, and don't format anything. Once I see the output, the next step is to mount the disk read-only and look at what came back. Read-only means nothing changes on the disk.