Pawel

Thats makes sense. Thak You for clarifying this issue. And give me a lot ways to fix it.

@John_M No Rock Ridge... so how ubuntu does it and shows filles with long names? Unraid even has newer version of mount: vs ubuntu: My iso: https://mega.nz/file/BVlnTCha#zYhZeS-vRYFBD1dbWiJie6KW6ZmzNuHeOjxdblWmDhQ

I had the same issue just right now. Helpful thread.

@johnnie.black 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... invalid start block 4177215269 in record 158 of bno btree block 1/5 agi unlinked bucket 59 is 264772539 in ag 1 (inode=2412256187) sb_icount 238784, counted 196928 sb_ifree 864, counted 1234 sb_fdblocks 181033632, counted 184201565 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 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 ... disconnected inode 2412256187, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (11:1332552) is ahead of log (1:2). Format log to cycle 14. done Reboot to normal mode? EDIT: Nice!. Got my shares back. Thank You @johnnie.black, @trurl

@johnnie.black 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. And i have no idea if it still running or not Guessing that now i should run it with '-L' flag?

@johnnie.black SwapFile plugin was doing some mess - it was trying to create swap on /mnt/cache/tmp_cache/. And this folder wasn't mounted so created file took all available disk space. Now i was able to do check: 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... invalid start block 4177215269 in record 158 of bno btree block 1/5 agi unlinked bucket 59 is 264772539 in ag 1 (inode=2412256187) sb_icount 238784, counted 196928 sb_ifree 864, counted 1234 sb_fdblocks 181033632, counted 184201565 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 2412256187, would move to lost+found Phase 7 - verify link counts... would have reset inode 2412256187 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting.

@johnnie.black Cant download diagnostics... after hitting download nothing happens. EDIT: Guessing that this can be an issue: Filesystem Size Used Avail Use% Mounted on rootfs 4.1G 4.1G 0 100% / tmpfs 34M 263k 34M 1% /run devtmpfs 4.1G 0 4.1G 0% /dev tmpfs 4.2G 0 4.2G 0% /dev/shm cgroup_root 8.4M 0 8.4M 0% /sys/fs/cgroup tmpfs 135M 2.0M 133M 2% /var/log /dev/sdb1 16G 582M 15G 4% /boot /dev/loop0 8.6M 8.6M 0 100% /lib/modules /dev/loop1 5.2M 5.2M 0 100% /lib/firmware Will try to free some space

@trurl sfejer-diagnostics-20190328-0755.zip

@trurl I cannot do that. "Check is only available when array is Started in Maintenance mode" After going to maintenance mode all my drives are in unassigned section. So don't have option to do fs check.

@trurl

Hi, not sure if this a correct way to get help here, but "unraid support" lead me here so... will try. I was doing: Deleting directory (rm -r some_dir). Using ssh i've logged in to unraid instance. Then went to directory ("cd /mnt/disk5/todo/"). And there do a delete operation. An now I have this error. Now: Did a few reboots, but always unmarked "write correction to parity" I don't see shares from that disk (disk5/sdc/WDC WD30EFRX-68EUZN0) in "shares" tab. Unable (or i don't know how) I would like to: I would like to be able to access my data. Best case: i would like to just do something to have my shares back Worst case: I have spare disk (larger than broken one). And i think I would be able to just copy data to that one, format oryginal one and move them back. But still have no idea how to achive that. Basically have no idea what to do to just... see my shares Any advices are welcome. Thank You in advance. sfejer-diagnostics-20190327-2252.zip