trurl

Reading my post just before yours though I also didn't tell you not to do this. And the thing you added to this idea was the last step in the procedure. If you had left that last bit off you would have been able to see what you would rebuild (to another disk), but without actually starting the rebuild on the same disk. So I guess we will see what you have after the rebuild and (re)repair of the filesystem.

This is exactly the procedure used to get Unraid to do the rebuild to the same disk. I don't remember anybody telling you to actually do this though. FTFY And when its done you will be back to where you were before you repaired the filesystem in the other computer. The reason it returned to "unmountable" is because that is what it is rebuilding.

Does the command line still work when this happens? Have you tried tailing the syslog to see if there is anything output when this happens? See the Need Help sticky pinned near the top of this same subforum for ideas on getting more information (if possible).

Just noticed you don't have parity. If you did then you would have been able to start the array with the disk emulated by the parity calculation. And you would be able to rebuild to another disk if necessary. That's a lot of disks to not have parity. Any reason why you don't? Do you have another copy of anything important and irreplaceable? That should be your first priority.

The apctest command is documented in the APCUPSD User Manual, which you can access from a link in the Unraid webUI in Settings - UPS Settings.

When you did the filesystem repair, did it create a lost+found folder? Just to simplify the discussion, let's disregard any writes to the array that may have happened since the disk was repaired in another system. If you remove the disk (or just unassign it) and start the array, the disk will be emulated from the parity calculation. Parity plus all other disks will be read to calculate the data of the missing disk. Of course, in your situation, that may be different than the actual contents of the physical disk at this point. The emulated disk is what would be rebuilt if you replaced the disk. Since parity wasn't involved in the repair of the filesystem, presumably the emulated disk still has filesystem corruption. You could rebuild the disk, then repair it's filesystem (in the array, not like you did before), or, you could even repair the emulated filesystem, then rebuild the disk. I think there is a very good chance that the end result would be the same as far as the disk contents are concerned, but maybe a slim chance it would turn out slightly differently. You would still have to figure out what the differences between the two results were. Looks like this is the first mention of backups anyone has made in the thread. I usually say something about it before this point. Do you have another copy of anything important and irreplaceable? That should be your first priority.

Can you ping docker hub from your server? What do you have for DNS?

It might be useful to know what your situation is. Ideally, the number of disks won't affect parity syncs, etc., and it would primarily depend on the size and speed of parity. But in the real-world there can be controller bottlenecks for example. How long does your 8TB parity check take? You can go to Main - Array Operations and click the History button for the answer.

OK that doesn't look too bad as far as writes. Of course, those numbers are reset on reboot so I don't know if those are all that has happened in the array since the disk was modified (repaired) in another system. But lets go back in the thread a bit for why we are considering going to a lot of extra time and effort (and expense of a new disk) to try a rebuild from parity instead of just getting parity back in sync with the already repaired disk. What evidence do you have for your 95% certainty.

Is it actually failing a test, or does the UPS just think the battery is too old because it doesn't know you replaced it?

These days IT is a collections of specialties that often have trouble communicating with each other. I'm sure many IT professionals know little about many of the things that are important when dealing with Unraid. I get the impression that most people do not know what "format" actually does, for example.

THIS^ If you move from one user share to another, linux sees all the user shares as having the same mount and so it just "renames" the files/folders so they have a different path on the same disk. This behavior often surprises people because something moved from a cache-only share to a cache-no share may stay on cache in a folder for that cache-no share on the cache drive. The workaround is to copy from source to destination followed by a delete from source. Copy forces a new write and so obeys the user share settings. I just tried this again to confirm and it does exactly as I said. I moved a file from a cache-only share to a cache-no share. The move was instantaneous. Checking the actual disks shows that a new folder for the cache-no share exists on cache with the file in it. So it was just "renamed" to a new path on the same disk.

I was going to comment on that screenshot, but instead let me ask for a different version of that screenshot. That screenshot is showing us the speed in the Reads and Writes column. It would be more relevant to know whether or not you (or anything else) have written to the array at all since putting the disk back. Just above the "View" label in the column with the folder icons is another icon. Click on it and it will show us the total number of reads and writes instead of the speed as you have it now. Give us that screenshot.

Not exactly wrong, but incomplete and not really up-to-date on how preclear fits into Unraid these days. Also note that the only time Unraid requires a clear disk is when adding it to a new data slot in an array that already has valid parity, so parity will remain valid. A replacement disk, for example, doesn't need to be clear since it will be completely overwritten by the rebuild anyway. And, Unraid will clear a disk in that one scenario where it requires a clear disk. The historical reason for preclear is because Unraid would take the array offline when it cleared a disk, so preclear was invented to clear the disk before adding it so Unraid wouldn't need to take the array offline. Additional testing functionality was builtin to preclear to help weed out the "infant mortality". Recent versions of Unraid do not take the array offline when it clears a disk, so the only function preclear has these days is testing.

For those people who already know everything that is in there then maybe it doesn't provide any additional information. For others who are just trying to figure out dockers and are having the issue maybe they find it useful. Without going to the trouble to search your history it is difficult for us to know whether you are one of those that already knows it all.

Nothing obvious in syslog. Most of your disks are completely full but that shouldn't affect rebuild since the parity calculation doesn't know anything about that. Not sure what that is about but ata4 is your cache drive so shouldn't affect the rebuild either. Jan 16 16:49:16 Tower kernel: ata4.00: ATA-9: Crucial_CT960M500SSD1, 1330094769B4, MU03, max UDMA/133 You have such a large number of disks that instead of going through SMART for each I will just ask you. Are any of your disks showing warning SMART indicators on the Dashboard page? Do you have anything in the Errors column in Main?

OK. Sorry for being a bad cop. There was a lot of time between some of these. And you did pull it all back together by linking to the other threads. Thanks for the wrapup. Hope it continues to work for you.

Go to Tools - Diagnostics and attach the complete Diagnostics zip file to your next post. Can you see the disk in the BIOS?

Have you read the "Docker Image Filling Up" section in the Docker FAQ: https://forums.unraid.net/topic/57181-real-docker-faq/

We usually let those people who want to try it that way provide support for each other over in the Virtualizing Unraid subforum: https://forums.unraid.net/forum/46-virtualizing-unraid/ The Unraid forums are mostly about users helping users anyway, and that subforum is a subset of those users who are trying to do something that is "officially unsupported" by Limetech (the Unraid company). Maybe your friend could help.

This increased logging for an extended time will probably fill your log space. If it does you will have to reboot to clear it out.

And a warning. Don't mix disks and user shares when moving/copying files or you can lose that data. Only move/copy from user share to user share, or from disk to disk.

I would try to clean this up but it is all just too old and too much trouble. I'm sorry I didn't notice any of this way back then, I would have cleaned it up before it got this bad and tried to get the user to quit doing it. @PR. Please, please don't do this again. Stick to one thread so we can all keep all of the information together. I really don't see why you would have even considered starting another and then another thread without any context for anybody. It would take a lot of trouble for us to even realize these were all the same person talking about the same problem.

This suggests to me that you are thinking of your Unraid as individual disks. That is one way to do it, but it is less flexible and bypasses some of the features of Unraid, such as disk spanning and write caching. I recommend working with User Shares. These are just the top folders on the disks. Any top level folder with the same name on multiple disks is part of the same user share. This is how Unraid allows you to span disks. You can refer to the user share name (folder name) and it will take care of figuring out which disk(s) are involved. Each user share has settings that gives you a lot of control over how each user share uses the disks, including whether and how cache is used. See this overview of User Shares in the wiki: https://wiki.unraid.net/UnRAID_6/Overview#User_Shares

If you want to rebuild to a new disk then you have to assign a replacement to the same slot. Probably that is what you mean. If however you want to add a disk to a new slot then that is a completely different process. 👍