March 8, 20242 yr Hi all... my setup mysteriously got this error. I've searched the forum and followed the diagnostic advice. This is the output of the filesystem 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... sb_ifree 33068, counted 33075 sb_fdblocks 2448669658, counted 2453742304 - 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 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 2 - agno = 1 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 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... No modify flag set, skipping filesystem flush and exiting. And attached is the log. Can someone please advice? This looks scary catastrophic. tower-diagnostics-20240308-1114.zip
March 8, 20242 yr Author 7 minutes ago, JorgeB said: Run it again without -n, and if it asks for -L use it. Hi @JorgeB, thanks so much for the quick response. I ran -n, and then had to do -L. This is the output after the repair: 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 sb_ifree 33068, counted 33075 sb_fdblocks 2448669658, counted 2453742304 - 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 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 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 (35:2939140) is ahead of log (1:2). Format log to cycle 38. done
March 8, 20242 yr Community Expert Should be fixed now, start the array in normal mode, look for a lost+found folder
March 8, 20242 yr Author Whew, thank you! @JorgeB I also lost my dockers... from what I read, I can go to the Apps tab and look at Previous Apps and reinstall from there... would that be safe to do? [I'm not seeing a lost+found folder unless I'm looking in the wrong places, or maybe there isn't one?] Edited March 8, 20242 yr by vurt
March 8, 20242 yr Community Expert 1 minute ago, vurt said: would that be safe to do? Should be as long as appdata is intact: https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file Also see below if you have any custom docker networks: https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks
March 8, 20242 yr Author @JorgeB Sorry, hopefully this is the last question... my dockers are back, but sabnzbd is having difficulty starting up "Execution Error". I removed it, and reinstalled it from the user template, and still getting the error. This is the output from the install: docker run -d --name='sabnzbd' --net='lsio' -e TZ="America/New_York" -e HOST_OS="Unraid" -e HOST_HOSTNAME="Tower" -e HOST_CONTAINERNAME="sabnzbd" -e 'PUID'='99' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:8080]/' -l net.unraid.docker.icon='https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/img/sabnzbd-icon.png' -p '8080:8080/tcp' -p '9090:9090/tcp' -v '/mnt/user/appdata/downloads/':'/downloads':'rw' -v '/mnt/user/appdata/downloads/incomplete/':'/incomplete-downloads':'rw' -v '/mnt/user/appdata/sabnzbd':'/config':'rw' 'linuxserver/sabnzbd' 9a17b4e103d196ccd1bc70ca2424698d2fb1ff9bb8309c50a6e039963da7e688 docker: Error response from daemon: driver failed programming external connectivity on endpoint sabnzbd (8314f2297d197ff8245f283a14065cc78112e31c5c4cdfc1a5cd5b418f3eeb89): Error starting userland proxy: listen tcp4 0.0.0.0:9090: bind: address already in use. The command failed. I can see there's a conflict with the bind address but I don't know what that actually means or how to resolve. Thanks so much for your help!
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.