July 2Jul 2 Noticed a disk was offline. Shut it down, verified all connections and started it back up. Met with Unmountable: wrong or no file system. Nearly every reboot has caused a parity re read lately so that is not good timing.Also unable to start in maintenance mode. Check the box, hit start and it just reloads the page.Got it into maintenance mode after a couple reboots. Disk 7 xfs check saysPhase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now.Clicking fix results inPhase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.tower-diagnostics-20260702-1337 2.zip Edited July 2Jul 2 by jmztaylor
July 3Jul 3 Community Expert You will need to zero the log, it's the only option to try and fix the filesystem, and most often it is not a problem.
July 8Jul 8 Community Expert I assume the disk dropped again first? If yes, it would be good to check the diags.
July 8Jul 8 Community Expert disk7 was already disabled in the diags, not even assigned, do you have the diags from when it last dropped, or was it never replaced since the 1st post?
July 8Jul 8 Author 24 minutes ago, JorgeB said:disk7 was already disabled in the diags, not even assigned, do you have the diags from when it last dropped, or was it never replaced since the 1st post?It wasn't replaced as after repair it was functioning again. Currently if I try to assign the disk to the array it wants to format it and doesn't even emulate the contents.
July 8Jul 8 Community Expert Ahh, OK, in that case you can try to repair the filesystem again, but it may be a good idea to make sure backups are up to date, if it happens once more, I would recommend reformatting just that filesystem and restoring the data.
July 8Jul 8 Author Just now, JorgeB said:Ahh, OK, in that case you can try to repair the filesystem again, but it may be a good idea to make sure backups are up to date, if it happens once more, I would recommend reformatting just that filesystem and restoring the data.I did but its still not wanting to mount it without formatting it. Just for ease, I am able to mount it with unassigned plugin and moving everything off of it right now. I will just add it to the array again and format it when done
July 8Jul 8 Author 2 minutes ago, JorgeB said:Please post the output from xfs_repair on the emulated disk.Its not emulated. /mnt/disk7 does not exist. Even though the webui says emulated. I can verify the files on disk7 do not exist in the shares they were assigned.
July 8Jul 8 Community Expert According to diags it exists; it's just not mounting:Jul 8 10:14:36 Tower emhttpd: shcmd (141): mount -t xfs -o noatime,nodiscard,nouuid /dev/mapper/md7p1 /mnt/disk7With the array started, post the output fromxfs_repair -v /dev/mapper/md7p1
July 8Jul 8 Author 1 minute ago, JorgeB said:According to diags it exists; it's just not mounting:Jul 8 10:14:36 Tower emhttpd: shcmd (141): mount -t xfs -o noatime,nodiscard,nouuid /dev/mapper/md7p1 /mnt/disk7With the array started, post the output fromxfs_repair -v /dev/mapper/md7p1root@Tower:~# xfs_repair -v /dev/mapper/md7p1Phase 1 - find and verify superblock... - block cache size set to 1503144 entriesPhase 2 - using internal log - zero log...zero_log: head block 2063886 tail block 2063868ERROR: The filesystem has valuable metadata changes in a log which needs tobe replayed. Mount the filesystem to replay the log, and unmount it beforere-running xfs_repair. If the filesystem is a snapshot of a mountedfilesystem, you may need to give mount the nouuid option. If you are unableto mount the filesystem, then use the -L option to destroy the log andattempt a repair. Note that destroying the log may cause corruption --please attempt a mount of the filesystem before doing this.
July 8Jul 8 Author I have already moved too much stuff around and off of disk7. I will just finish moving everything and add it back and format it. Is this a possible drive issue or just something got messed up?
July 9Jul 9 Community Expert You would need to use -L, for now, it just looks like a filesystem issue.
July 14Jul 14 Author reformatted the drive. Invalidated parity. Let it rebuild parity. And now 5 days later same thing happening.tower-diagnostics-20260714-1004 2.zip
July 14Jul 14 Community Expert There are a lot of ATA errors logged for ATA6, which is disk 7, likely not a coincidence. Replace both cables for that disk to see if they stopJul 14 10:03:53 Tower kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)Jul 14 10:03:53 Tower kernel: ata6: EH completeJul 14 10:03:53 Tower kernel: ata6.00: exception Emask 0x50 SAct 0x80fe3ffc SErr 0x40f0802 action 0xe frozenJul 14 10:03:53 Tower kernel: ata6.00: irq_stat 0x00400000, PHY RDY changedJul 14 10:03:53 Tower kernel: ata6: SError: { RecovComm HostInt PHYRdyChg PHYInt CommWake 10B8B DevExch }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/00:10:68:4f:00/01:00:00:00:00/40 tag 2 ncq dma 131072 inJul 14 10:03:53 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/00:18:68:50:00/01:00:00:00:00/40 tag 3 ncq dma 131072 inJul 14 10:03:53 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }### [PREVIOUS LINE REPEATED 1 TIMES] ###Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/00:40:68:5d:00/01:00:00:00:00/40 tag 8 ncq dma 131072 inJul 14 10:03:53 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/48:50:68:5f:00/00:00:00:00:00/40 tag 10 ncq dma 36864 inJul 14 10:03:53 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/b8:58:b0:5f:00/01:00:00:00:00/40 tag 11 ncq dma 225280 inJul 14 10:03:53 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/78:60:68:61:00/00:00:00:00:00/40 tag 12 ncq dma 61440 inJul 14 10:03:53 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/00:68:e0:61:00/01:00:00:00:00/40 tag 13 ncq dma 131072 inJul 14 10:03:53 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: cmd 60/00:90:68:54:00/01:00:00:00:00/40 tag 18 ncq dma 131072 inJul 14 10:03:53 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 14 10:03:53 Tower kernel: ata6.00: status: { DRDY }Jul 14 10:03:53 Tower kernel: ata6.00: failed command: READ FPDMA QUEUEDJul 14 10:03:53 Tower kernel: ata6.00: cmd 60/00:98:68:55:00/01:00:00:00:00/40 tag 19 ncq dma 131072 inJul 14 10:03:53 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)
July 15Jul 15 Author Replaced both. Went back through the process of repairing filesystem. Said it was corrected. Parity check started on array start. Logs are showing this nowKul 15 13:05:08 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:05:08 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:08 Tower kernel: ata7: EH complete Jul 15 13:05:14 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x1c000 SErr 0x400000 action 0x6 frozen Jul 15 13:05:14 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 15 13:05:14 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:14 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:14 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:14 Tower kernel: ata7.00: cmd 61/80:80:a8:d2:ad/00:00:7d:01:00/40 tag 16 ncq dma 65536 out Jul 15 13:05:14 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:14 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:14 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:05:14 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:14 Tower kernel: ata7: EH complete Jul 15 13:05:20 Tower kernel: ata7.00: exception Emask 0x10 SAct 0xfc4 SErr 0x400000 action 0x6 frozen Jul 15 13:05:20 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 15 13:05:20 Tower kernel: ata7: SError: { Handshk } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: cmd 61/40:10:c8:e5:ba/05:00:7d:01:00/40 tag 2 ncq dma 688128 out Jul 15 13:05:20 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:20 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: cmd 61/20:30:08:eb:ba/01:00:7d:01:00/40 tag 6 ncq dma 147456 out Jul 15 13:05:20 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:20 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: cmd 61/38:58:a8:ad:bb/04:00:7d:01:00/40 tag 11 ncq dma 552960 out Jul 15 13:05:20 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:20 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:05:20 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:20 Tower kernel: ata7: EH complete Jul 15 13:05:25 Tower kernel: ata7: limiting SATA link speed to 3.0 Gbps Jul 15 13:05:25 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x2020 SErr 0x400000 action 0x6 frozen Jul 15 13:05:25 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 15 13:05:25 Tower kernel: ata7: SError: { Handshk } Jul 15 13:05:25 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:25 Tower kernel: ata7.00: cmd 61/40:28:50:36:24/05:00:7f:01:00/40 tag 5 ncq dma 688128 out Jul 15 13:05:25 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:25 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:25 Tower kernel: ata7.00: cmd 61/40:68:90:3b:24/05:00:7f:01:00/40 tag 13 ncq dma 688128 out Jul 15 13:05:25 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:25 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:25 Tower kernel: ata7: hard resetting link Jul 15 13:05:25 Tower kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Jul 15 13:05:25 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:25 Tower kernel: ata7: EH complete
July 16Jul 16 Community Expert That's a different disk, assuming ports were not swapped, but it also looks like a power/connection issue. Any power splitters in use? It could also be a bad/weak PSU
July 17Jul 17 Author On 7/16/2026 at 1:38 AM, JorgeB said:That's a different disk, assuming ports were not swapped, but it also looks like a power/connection issue. Any power splitters in use? It could also be a bad/weak PSUIts a 700w psu that only has about a year of usage on it. I swapped around every drive and cable, pulled the GPU in case that was the issue, and moved the problem drive to a different sata controller. Nothing would make the issue go away. I pulled the drive completely and no longer seeing any errors on any drive. I don't want to lose that much storage but tired of dealing with this issue.
July 17Jul 17 Community Expert It's possible the drive is the problem; sometimes SMART can look OK, and the errors are not logged as a disk problem, and it still is.
July 17Jul 17 Author 1 hour ago, JorgeB said:It's possible the drive is the problem; sometimes SMART can look OK, and the errors are not logged as a disk problem, and it still is.Yeah thats where I am going with this. If I remember right one of my wd 4tb drives was a warranty claim and is a refurb. So I am just going to try that route and leave it out, as I haven't seen a single issue since pulling it completely
July 19Jul 19 Author Still not quite solved. Pulled that disk and switched to a different PSU. All sata cables were replaced also. And it stayed at ata7 but switched to disk 1. Now its only happening in one loop instead of consistent like before. And according to the logs only happened twice since this boot yesterday.Jul 19 04:49:02 Tower emhttpd: read SMART /dev/sdfJul 19 04:59:27 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal errorJul 19 04:59:27 Tower kernel: ata7.00: failed command: READ FPDMA QUEUEDJul 19 04:59:27 Tower kernel: ata7.00: cmd 60/00:00:d8:ce:58/02:00:5e:00:00/40 tag 0 ncq dma 262144 inJul 19 04:59:27 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)Jul 19 04:59:27 Tower kernel: ata7.00: cmd 60/00:f8:d8:cc:58/02:00:5e:00:00/40 tag 31 ncq dma 262144 inJul 19 04:59:27 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)Jul 19 04:59:27 Tower kernel: ata7.00: status: { DRDY }Jul 19 04:59:27 Tower kernel: ata7: hard resetting linkJul 19 05:12:03 Tower emhttpd: spinning down /dev/sdj Edited July 19Jul 19 by jmztaylor
July 20Jul 20 Community Expert It could also be an issue with the controller, or just those specific ports.
July 20Jul 20 Author 3 hours ago, JorgeB said:It could also be an issue with the controller, or just those specific ports.I have another pc with same mb/ram/cpu. I swapped out those 3 and haven't seen a single issue. The other pc doesn't use the sata ports. So hopefully this is the end of this.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.