lahger Posted March 3 Share Posted March 3 Hello awesome community! Today I was playing around with a docker container, for some reason it broke after an edit. I had some other dockers routed through it (I was editing binhex-delugeVPN) and after a 403 error when I tried to start it I took a look at the log of the container and it said a identical container-ID needed to be removed to start up the first one, so I did that with "docker rm #containerID". Then all hell broke loose. After a reboot the docker service can't start. So I did a restore of the container with the Backup/restore Appdata plugin. Did a smart status check of the drive, without errors. Then I did a parity-check as a just in case, then I rebooted again and now my only array drive is unmountable.. I am at a loss here and desperately need help saving my data. Thanks in advance! nas-syslog-20240303-2152.zip Quote Link to comment
Solution JorgeB Posted March 4 Solution Share Posted March 4 Check filesystem on disk1, run it without -n. Quote Link to comment
lahger Posted March 4 Author Share Posted March 4 1 hour ago, JorgeB said: Check filesystem on disk1, run it without -n. Thanks for the reply, all i get is this error: "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." Quote Link to comment
itimpi Posted March 4 Share Posted March 4 You need to run without -n and add -L Quote Link to comment
lahger Posted March 4 Author Share Posted March 4 Ok so i got this: 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 invalid start block 2431640529 in record 22 of cnt btree block 2/1406531 invalid start block 550648526 in record 23 of cnt btree block 2/1406531 agf_freeblks 51159384, counted 51159376 in ag 2 agi unlinked bucket 3 is 1019587 in ag 1 (inode=1074761411) sb_ifree 5850, counted 5851 sb_fdblocks 335077470, counted 340134580 - 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 bad CRC for inode 7049496543 bad CRC for inode 7049496543, will rewrite cleared inode 7049496543 - agno = 7 - 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 = 2 - agno = 4 - agno = 7 - agno = 5 - agno = 3 - agno = 6 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 1074761411, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (35:914517) is ahead of log (1:2). Format log to cycle 38. done Any ideas? Quote Link to comment
itimpi Posted March 4 Share Posted March 4 The dtive should now mount when the array is started innNormal mode. You should check whether this a Lost+Found folder on the drive - this is where the repair process would put any files/folders for which it could not find the directory entry to give them their correct name. Quote Link to comment
lahger Posted March 4 Author Share Posted March 4 Oh thank you so much, the drive is back alive! There is one file in the lost+found but the file is empty, the name of said file is 1074461411 if that is of any use. Quote Link to comment
itimpi Posted March 4 Share Posted March 4 3 minutes ago, lahger said: Oh thank you so much, the drive is back alive! There is one file in the lost+found but the file is empty, the name of said file is 1074461411 if that is of any use. The name is always something cryptic (since the directory entry cannot be found). If it is empty you can simply delete it. Quote Link to comment
lahger Posted March 4 Author Share Posted March 4 1 minute ago, itimpi said: The name is always something cryptic (since the directory entry cannot be found). If it is empty you can simply delete it. Alright, thank you all for the help, gotta love this awesome community! I think it is time to start following the 3-2-1 rule for my data now.. Quote Link to comment
Recommended Posts
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.