March 3, 20242 yr Hi I just did the update 6.12.8 and I lost all my dockers and I have one drive which I get the following error "unmountable : unsupportable file system" any ideas , Should I shut down the array and restart ? Regards zeus-diagnostics-20240303-1626.zip Edited March 3, 20242 yr by madmax969
March 4, 20242 yr Community Expert 1 hour ago, snowboardjoe said: docker: invalid spec: :/usr/src/app/bin:rw: empty section between colons. It is no longer allowed to have empty mappings in your docker. Either delete them (best way), or install the Docker Patch plugin, which will allow them again.
March 4, 20242 yr Community Expert 1 hour ago, snowboardjoe said: Similar situation here Maybe not. Sorry for the hijack @madmax969 You need to check filesystem on disk1. Do it from the webUI and not the command line. Post the output.
March 4, 20242 yr Community Expert As for your dockers, since disk1 is unmountable, any files that were there aren't currently available to user shares. Your appdata, domains, and system shares are on cache where they belong, but perhaps these were newly created because they had been on disk1 which is currently unavailable. I see you have a deprecated Appdata Backup plugin installed, so don't know if you do have appdata backups. We can deal with all that after you check filesystem on disk1.
March 4, 20242 yr Author hi @trurl, I tried to run the checkfile system and I receive the following error " Phase 1 - find and verify superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now."
March 4, 20242 yr Author it worked with removing the -n hase 1 - find and verify superblock... writing modified primary superblock sb root inode value 128 inconsistent with calculated value 96 resetting superblock root inode pointer to 96 sb realtime bitmap inode value 129 inconsistent with calculated value 97 resetting superblock realtime bitmap inode pointer to 97 sb realtime summary inode value 130 inconsistent with calculated value 98 resetting superblock realtime summary inode pointer to 98 Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... sb_icount 0, counted 352576 sb_ifree 0, counted 2450 sb_fdblocks 0, counted 66035540 - 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 = 3 - agno = 1 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... done
March 5, 20242 yr Author sorry for the late reply here is the new log zeus-diagnostics-20240305-1227.zip
March 5, 20242 yr Community Expert Looks like disk1 is mounted now and with plenty of data. And repair didn't result in any lost+found. On 3/3/2024 at 10:56 PM, trurl said: As for your dockers, since disk1 is unmountable, any files that were there aren't currently available to user shares. Your appdata, domains, and system shares are on cache where they belong, but perhaps these were newly created because they had been on disk1 which is currently unavailable. And system share does indeed have files on disk1. Appdata is all on cache still so that is good. Do you have any VMs? You didn't mention them but their definitions would also have been recreated. Were they still working? Probably if you get rid of the newly created system share on cache, and move the system share from disk1 to cache where it belongs, you will be good. You have Dynamix File Manager plugin, so you can use that for the cleanup. But, nothing can move or delete open files. You have to disable Docker and VM Manager in Settings before you can work with these.
March 5, 20242 yr Author Hi Thanks for the quick response I do not have have any VMS How do I get rid of and move the files "Probably if you get rid of the newly created system share on cache, and move the system share from disk1 to cache where it belongs, you will be good."
March 5, 20242 yr Community Expert 1 minute ago, madmax969 said: How do I get rid of and move the files I would suggest using the Dynamix File Manager plugin. This is going to be a standard part of the 6.13 release so a good idea to get used to it.
March 5, 20242 yr Community Expert User shares are simply the combined top level folders on array and pools. So you just need to get rid of the top level folder named system on cache, and move the top level folder named system on disk1 to cache.
March 5, 20242 yr Author HI , I am not sure exactly what you mean by "So you just need to get rid of the top level folder named system on cache, and move the top level folder named system on disk1 to cache. i see folders in Disk 1 like .Trash- Backup Downloads system and on Cache drive .Trash-99 appdata system
March 5, 20242 yr Community Expert The folder named "system" that you have listed there for each drive is exactly what I mean.
March 7, 20242 yr Author I started the moved and received the following message Use sparse option Overwrite existing files rsync: [receiver] write failed on "/mnt/cache/system/docker/docker.img": Read-only file system (30) rsync: [receiver] chown "/mnt/cache/system/docker/.docker.img.XaaVPz" failed: Read-only file system (30) rsync: [receiver] rename "/mnt/cache/system/docker/.docker.img.XaaVPz" -> "docker/docker.img": Read-only file system (30) rsync error: error in file IO (code 11) at receiver.c(380) [receiver=3.2.7] rsync: [sender] write error: Broken pipe (32)
March 7, 20242 yr Community Expert If your cache is read-only you have bigger problems. Post new diagnostics.
March 10, 20242 yr Community Expert On 3/7/2024 at 3:26 PM, trurl said: If your cache is read-only you have bigger problems. Post new diagnostics.
March 11, 20242 yr Author the system folder has been copied over from disk 1 to cache zeus-diagnostics-20240311-0201.zip
March 11, 20242 yr Community Expert Mar 1 14:09:27 Zeus kernel: XFS (md1p1): Corruption detected. Unmount and run xfs_repair There may be other issues but start by checking filesystem on disk1, run it without -n, then reboot to clear the logs and post new diags if there are more issues.
March 13, 20242 yr Author I can see my dockers I am uploading the latest diagnostic report Please let me know if there are any other errors zeus-diagnostics-20240313-1025.zip
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.