jgopel

Will do - `find / -name 'lost+found' -type d` didn't yield any results, so I think I'm in the clear there. Thanks again!

Ran that and got the following output: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 4 - agno = 9 - agno = 3 - agno = 1 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 10 - agno = 2 - agno = 11 - agno = 12 clearing reflink flag on inodes when possible Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (2:346049) is ahead of log (1:2). Format log to cycle 5. done Seems like the system is back to normal. Thanks for the help!

Been short on time to work on this, so I haven't been making progress, but I did try a normal xfs_repair (ie: no -n) on the old parity drive via the webUI. That results in the following output: Phase 1 - find and verify superblock... 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 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.

webUI diagnostics-20230624-1509.zip

Restarted the array in maintenance mode and ran xfs_repair status with options of -n on the new data drive (000J). Here are the results: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 7 - agno = 2 - agno = 4 - agno = 3 - agno = 5 - agno = 6 - agno = 8 - agno = 9 - agno = 10 - agno = 0 - agno = 11 - agno = 12 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... Maximum metadata LSN (2:346032) is ahead of log (2:345452). Would format log to cycle 5. No modify flag set, skipping filesystem flush and exiting.

No dice - seems to fail in exactly the same way that manually running mount failed in the OP.

Quick update here - rebuild finished and the old parity drive is still unmountable.

I don't recall whether or not I rebooted. I did do a parity copy and it did take quite a while (about 48hrs). Looking at my uptime, I feel like I must have rebooted after that, though I can't recall why I would have done that. I'm just very comfortable on the command line. At the point that the GUI wasn't giving me much information, I just started treating it like I would any of the other headless systems that I deal with. I'll get that plugin installed and see if there's any extra info.

I haven't looked closely at the contents of the diagnostics to know what you're going off of, but here are the disks in the system per lshw: root@Mnemosyne:~# lshw -class disk *-disk description: SCSI Disk product: SanDisk 3.2Gen1 vendor: USB physical id: 0.0.0 bus info: scsi@0:0.0.0 logical name: /dev/sda version: 1.00 serial: 0501e7d20d2b890a2a0f size: 57GiB (61GB) capabilities: removable configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512 *-medium physical id: 0 logical name: /dev/sda size: 57GiB (61GB) capabilities: partitioned partitioned:dos *-disk:0 description: ATA Disk product: WDC WD181KFGX-68 vendor: Western Digital physical id: 0 bus info: scsi@5:0.0.0 logical name: /dev/sdb version: 0A83 serial: 2JK9KVBB size: 16TiB (18TB) capabilities: gpt-1.00 partitioned partitioned:gpt configuration: ansiversion=5 guid=9d7f5e68-b1c3-4bfb-ab9a-b848cf92a01c logicalsectorsize=512 sectorsize=4096 *-disk:1 description: ATA Disk product: ST14000NM000J-2T physical id: 1 bus info: scsi@6:0.0.0 logical name: /dev/sdc version: SN01 serial: ZR701WCM size: 12TiB (14TB) capabilities: gpt-1.00 partitioned partitioned:gpt configuration: ansiversion=5 guid=2b9706e5-5ebd-f477-59bc-3324c5e6672f logicalsectorsize=512 sectorsize=4096 *-disk:2 description: ATA Disk product: Samsung SSD 850 physical id: 2 bus info: scsi@7:0.0.0 logical name: /dev/sdd version: 2B6Q serial: S250NXAGC05587N size: 476GiB (512GB) capabilities: partitioned partitioned:dos configuration: ansiversion=5 logicalsectorsize=512 sectorsize=512 *-disk:3 description: ATA Disk product: ST14000NM001G-2K physical id: 3 bus info: scsi@8:0.0.0 logical name: /dev/sde version: SN03 serial: ZL2N0TCM size: 12TiB (14TB) capabilities: gpt-1.00 partitioned partitioned:gpt configuration: ansiversion=5 guid=f459f699-abb9-3556-ca5f-11f834a78b64 logicalsectorsize=512 sectorsize=4096 The 2 Seagate drives were the original data (/dev/sde - 001G) and original parity/new data (dev/sdc - 000J). The new parity drive is the Western Digital (/dev/sdb - KFGX). 001G was replaced in the array by KFGX (though I haven't gone to the effort of PHYSICALLY removing it from the system yet). It is fine for you to think of 001G as having been replaced by KFGX from the perspective of the array. Does that clear things up at all?

I added a drive to the system, but I replaced the data drive in the array. The old data drive is currently in the system, powered, etc but not assigned. In fact, the mount and dmesg logs from above are from the original data disk.

All after the upgrade.

After upgrading from 6.11.5 to 6.12.1 I could not start my array because my data drive was showing as "Unmountable: Unsupported or no file system". I added a new drive to the system with the intent of rebuilding from parity. The new drive happens to be larger than the old parity drive, so I did a Parity Swap Procedure. The copy succeeded as far as I can tell. When I began the rebuild on the new data drive (ie: the old parity drive), it started showing the same "Unmountable" error. The rebuild has not finished yet, but I expect I will be in the same state I started in at the end of it. What is this error trying to tell me? Could this be related to the OS update? Some additional info: The old data drive is now completely idle, so I decided to see if I could diagnose it any further: root@Mnemosyne:~# mount /dev/sde1 foo mount: /root/foo: wrong fs type, bad option, bad superblock on /dev/sde1, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. root@Mnemosyne:~# dmesg | tail -10 [91533.996720] less[12157]: segfault at 1a496 ip 00000000004057e7 sp 00007ffc1d2720e0 error 4 in less[402000+1a000] likely on CPU 1 (core 0, socket 0) [91533.996781] Code: 8b 04 24 41 8b 8c 24 40 80 00 00 e9 05 fd ff ff 48 c7 c5 d8 f4 42 00 45 85 ed 0f 84 93 00 00 00 bf fa 00 00 00 e8 89 0d 01 00 <8b> 55 00 85 d2 75 08 41 bd 01 00 00 00 eb ab 48 c7 c0 e8 2d 43 00 [113884.439807] XFS (sde1): Mounting V5 Filesystem [113884.503022] XFS (sde1): Corruption warning: Metadata has LSN (2:346049) ahead of current LSN (2:345452). Please unmount and run xfs_repair (>= v4.3) to resolve. [113884.503041] XFS (sde1): log mount/recovery failed: error -22 [113884.503292] XFS (sde1): log mount failed [114218.204375] XFS (sde1): Mounting V5 Filesystem [114218.250007] XFS (sde1): Corruption warning: Metadata has LSN (2:346049) ahead of current LSN (2:345452). Please unmount and run xfs_repair (>= v4.3) to resolve. [114218.250018] XFS (sde1): log mount/recovery failed: error -22 [114218.250192] XFS (sde1): log mount failed This led me to this thread, which seems vaguely related. diagnostics-20230623-1623.zip

Hi, thanks for the response. I think I communicated the situation badly - the WAP has LAN ports on it, so both connections are already wired connections. For a bit more color, there are WAPs throughout the property. Each resident has separate login information and a separate VLAN that their devices connect to. Wired connections into the WAP LAN ports end up on the same VLAN. This allows me to, eg, take a laptop to the roof and work up there while still being on the same network as the devices in my unit. The only configuration that the IT company that manages the WAPs was able to provide me where I was able to have a connection that was not behind a double NAT was to reconfigure one of the LAN ports on the WAP so that it's public. I understand that UnRAID is not designed to be publicly facing and grasp the challenges that that creates for management. What I'd like to do is to have the wired connection from that port be used as the primary interface for my Plex container. I still need UnRAID to be on the VLAN, as that's where all the devices I'll be using to manage it are. Does that clear things up at all?

I live in an apartment in a building where my internet connection is operated by a third party company. They've configured the network such that I am double-NAT'd and are unwilling/unable to reconfigure it for just one NAT or do port forwarding for me. What they've done as a compromise is to assign me a public, static IP that's bound to one of the ports on the Ruckus WAP that's in my apartment. Until recently, I was running a dual-NIC system (not UnRAID) with one NIC connected to the double-NAT'd private network and one connected to the port and configured with the static IP, etc. The interface for the public network was only exposed to Plex so that Plex remote access works without having the extra hop through Plex’s servers. I recently moved my media server to an UnRAID system and I've been super happy with it. I’ve gotten everything setup on the local network connection and now I’m trying to configure the public side of the networking. The primary goal here is to allow Plex remote access without having to go through Plex servers (to avoid losing quality). I’ve added a second NIC to the system (BCM5751 over PCIe, just in case it’s relevant), but it’s causing issues.It seems that I need to disable bonding so that the local and public interfaces don’t conflict and so that management stays available on the local network. I am not sure how UnRAID expects bridging to be configured in this situation, but I think having 2 bridges might be the solution. I’ve tried a number of approaches here that all seem to lead to lookup failures for tower.local at some stage, either in configuring networking or when the 2nd interface becomes active. Is what I’m trying to do supported on UnRAID? If so, what’s the intended configuration to get it working? Thanks in advance!