I finally upgraded to 7.x from 6.9.2 and one of my drives no longer mounts. I then downgraded back to 6.9.2 and the problem persists.

1. xfs_status shows: Not available

   1. Trying Check anyway does not appear to even attempt to fix anything, when run without flags.
      

2. Running xfs_repair -v /dev/md6p1 yields :
   /dev/md6p1: No such file or directory

   /dev/md6p1: No such file or directory

   fatal error -- couldn't initialize XFS library
   
   To ensure I'm running that correctly, this is Disk 6, so md6p1 should be correct, right?
   

3. Unraid was running fine prior to the upgrade.
   

4. Every test I've run on the drive shows good. I can run any specific tests you want.
   

5. My last parity check was about a month ago and I have not had a single error since I upgraded my drives ~4 years ago.

Any help is greatly appreciated.

tower-diagnostics-20260808-1909.zip

Diags after the start, please. Also, did you do anything else after upgrading, other than just downgrading, like a New Config?

I did nothing else. I've never used Docker, but was thinking of installing Pi Hole in Docker. So I wanted to be fully up to date before doing anything.

I hit upgrade, rebooted when it said to, and the issue was there immediately.

For the diags, I rebooted and started in Maintenance mode. Is that what you wanted or did you want me to start it in normal mode?

tower-diagnostics-20260809-1047.zip

3 hours ago, thekiltedwonder said:

I did nothing else. I've never used Docker, but was thinking of installing Pi Hole in Docker. So I wanted to be fully up to date before doing anything.

I hit upgrade, rebooted when it said to, and the issue was there immediately.

For the diags, I rebooted and started in Maintenance mode. Is that what you wanted or did you want me to start it in normal mode?

tower-diagnostics-20260809-1047.zip

normal mode please, maintenance mode doesnt mount disks so it wont show any errors

I rebooted and started the array. Here is the diag file from immediately after doing that.

tower-diagnostics-20260809-1441.zip

disk6 appears to be mounting correctly

Aug  9 13:41:06 Tower emhttpd: shcmd (63): mkdir -p /mnt/disk6
Aug  9 13:41:06 Tower emhttpd: shcmd (64): mount -t xfs -o noatime /dev/md6 /mnt/disk6
Aug  9 13:41:06 Tower kernel: XFS (md6): Mounting V5 Filesystem
Aug  9 13:41:06 Tower kernel: XFS (md6): Ending clean mount
Aug  9 13:41:06 Tower kernel: xfs filesystem being mounted at /mnt/disk6 supports timestamps until 2038 (0x7fffffff)
Aug  9 13:41:06 Tower emhttpd: shcmd (65): xfs_growfs /mnt/disk6
Aug  9 13:41:06 Tower root: meta-data=/dev/md6               isize=512    agcount=15, agsize=268435455 blks
Aug  9 13:41:06 Tower root:          =                       sectsz=512   attr=2, projid32bit=1
Aug  9 13:41:06 Tower root:          =                       crc=1        finobt=1, sparse=1, rmapbt=0
Aug  9 13:41:06 Tower root:          =                       reflink=1
Aug  9 13:41:06 Tower root: data     =                       bsize=4096   blocks=3906469875, imaxpct=5
Aug  9 13:41:06 Tower root:          =                       sunit=0      swidth=0 blks
Aug  9 13:41:06 Tower root: naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
Aug  9 13:41:06 Tower root: log      =internal log           bsize=4096   blocks=521728, version=2
Aug  9 13:41:06 Tower root:          =                       sectsz=512   sunit=0 blks, lazy-count=1
Aug  9 13:41:06 Tower root: realtime =none  

Unraid marked the disk as disabled, you will need to check the emulated contents and then if that looks good rebuild onto the disk.

SMART report looks ok

Stop the array, set the slot to "unassigned" and start the array, the contents should now be emulated, browse the disk and look to make sure everything is ok.

Stop the array again, re-assign the disk, and start the array, unraid will proceed to rebuild the emulated contents back onto the disk.

If the emulated contents or the emulated disk doesnt mount or doesnt look correctly, report back.

Edited Sunday at 08:55 PM2 days by MowMdown

Is there an easy way to check that disk specifically? My Shares are not assigned to any specific disks and all disks are near full.

My first thought is to just pull the drive and check it on my desktop, but if there is a better way, I can do that.

Also, how should I handle updating? Assuming everything looks good emulated, should I rebuild this first, then update and potentially need another rebuild? Or should I update first and then rebuild afterwards? Also, I have two new disks to go in. Would I be best off to rebuild to that and keep this one as is until I verify that everything is kosher with the rebuild?

Also, thanks a million.

you can try and mount the disk using the unassigned devices plugin and read it that way

Just be aware you will either have to rebuild the disk OR sync parity.

Edited Sunday at 09:03 PM2 days by MowMdown

1 minute ago, MowMdown said:

you can try and mount the disk using the unassigned devices plugin and read it that way

I've used that in the past and totally forgot. Perfect. Thanks!

Everything looks good. I'm going to go ahead and swap in a new disk and rebuild to that.

Unless something stupid happens, I think this is solved. I'll come back and officially mark it solved once the rebuild and update are done.

17 minutes ago, MowMdown said:

Stop the array, set the slot to "unassigned" and start the array, the contents should now be emulated

Contents of disabled disk is already emulated whether or not it is assigned and contents of physical disk aren't used for reading or writing until rebuild completes.

So it's possible emulated disk has some data that the physical disk does not since the disabled disk isn't used for any writes that happened after, they are emulated instead. The emulated writes can be recovered by rebuilding so that is the standard approach since the physical disk may not have everything.

2 minutes ago, thekiltedwonder said:

swap in a new disk and rebuild to that

Safest approach is to rebuild to a spare disk as you plan to do, so the original disk isn't changed. That way if there is some problem with the rebuild, the original is a "backup".

you can try and mount the disk using the unassigned devices plugin and read it that way

Thanks. There shouldn't be any writes after the issue popped up, I'm going the careful route anyway.

3 hours ago, trurl said:

contents of physical disk aren't used for reading or writing until rebuild completes

Just to pick my own nit here. It is possible to write to the rebuilding disk. If rebuild had not already progressed to that block of the physical disk, then parity update results in emulated write. If rebuild had already written the block, then the physical disk is written with the new data and parity updated as usual.

tower-diagnostics-20260810-1923.zip

For some reason my text was deleted when I hit submit.

It's working properly, but one thing happened that I did not understand. There are several files on the removed drive that are not on the rebuilt drive, but are on the server. Is that normal?

Other than that strangeness, it's working fine.

Edited 21 hours ago21 hr by thekiltedwonder

Delete is a write operation. If a file was deleted from the emulated drive, it wouldn't be on the rebuild, but would still be on the physical drive.

To be clear, it is still on the array, but not on this particular drive. That is what has me confused.

As soon as the issue happened, I did my best to ensure that nothing changed so I didn't accidentally overwrite anything. To that end, I made no changes after the drive wouldn't mount properly and had not added or removed anything from the drive in the prior couple of days.

If a file was moved from the emulated drive, it wouldn't be on the rebuild but would still be on the physical disk.

I think we are talking past each other. I understand what you are saying.

I did not move or delete anything on the emulated drive. Further, all files are still available and none have been deleted from teh array.

Because I did not move anything, I am trying to understand why certain files were on the original physical drive, but on a different physical drive after the drive was rebuilt.