trurl

Can you do it with a telnet/ssh client? What is the OS of your PC?

Answer this and if telnet/ssh, what OS are you working from? (Windows, iOS, etc.)

Like many of that brand, it doesn't have a single +12V rail.

What exactly are you trying to login to? If you're trying to login to Plex you would login using the account you have at Plex.

So is this the output of the tree command asked for? It would be much better to see the complete output as a screenshot exactly as it appears rather than some sort of transcription. How are you getting to the command line? Keyboard/monitor or telnet/ssh? Should be easy to get a screenshot from telnet/ssh client. For example, this is what that command gives me:

Did you actually try the command? Shouldn't matter whether you rebooted or not.

What exactly is the error? Are you saying that you can't navigate to /mnt/disk3/disk3?

jonathanm already gave good advice on how to proceed. Just wanted to comment on this bit. /mnt/user is the user shares. /mnt/user0 is the user shares excluding any files that are still on cache. If you see it in /mnt/user0, then it is also in /mnt/user. /mnt/user0 is really more of a "system" folder. The mover script works by moving files between /mnt/cache and /mnt/user0. But you don't want to work with the user shares for this, you want to work with the disks as jonathanm instructed. If you are not precise with this, it can cause confusion for yourself and those trying to help, and lead to instructions that might not work exactly right, or at all. As you know, computers take things very literally, and spaces and upper/lower case are significant in folder/filenames in linux.

That would be different than format normally works for all other operating systems, and for all other filesystems. And it would take a lot of needless time to write all those zeros when all formatting is trying to accomplish is a new filesytem. We already have another, separate process (actually more than one) for writing zeros to an entire disk.

If you are not concerned about maintaining parity, then of course you don't have to. The only thing you have to do to convert a disk from RFS to XFS is reformat it to XFS. The whole point of moving things around is so you don't lose any files when you reformat. There is absolutely no requirement to follow any instructions from anybody else. unRAID isn't going to care, since at any time a New Config will just tell it you are starting over with whatever is already on the disks that you assign at that time. I certainly didn't follow the wiki for this (that wiki didn't exist at the time). I just did it based on my understanding and my specific situation. I didn't need to add any drives since I already had enough empty space on my drives to allow me to move everything off them one at a time so I could reformat. And I maintained parity throughout. Other methods are certainly possible. For example, if you have good backups of everything then just start with a bunch of freshly formatted XFS disks (don't even need to be clear), copy everything to them, and build parity. But the backups for the really important irreplaceable files must be really trustworthy. I have multiple backups of those.

If the formatted disk was precleared just before formatting, then most of it would be zeros, but some of it would be the bits that represent the empty filesystem, and those would not be zero. If the formatted disk was not precleared, then some of it represents the empty filesystem, but the rest of the disk is unchanged from what it was before the format. You can assume much of it is not zeros. A formatted disk is not a clear disk. Format literally means "write an empty filesystem". And all filesystems are not the same, so how an empty filesystem is actually represented in the bits is different for different filesystems. And none of the filesystems represent an empty filesystem as all zeros. Formatting a disk when it is already part of the array maintains parity. The contents of the disk were already part of parity before the format, and formatting updates parity, because formatting is simply writing a few bits that represent an empty filesystem. Adding a clear disk to a new slot in the array maintains parity, because a clear disk is all zeros and has no effect on parity. Replacing a formatted disk with any other disk, whether clear or not, requires a rebuild of the replacement, or a rebuild of parity. Because the bits on the original and replacement disks are not the same. As far as parity is concerned, there are no files, and there are no filesystems. It is all just bits. A disk with an empty filesystem is a bunch of bits, and at least some of them are not zero, or there wouldn't be a filesystem there.

The "new drive" is already part of the array, so anything written to it from that point forward updates parity, and as already mentioned, everything is a write at the bit level, whether it is creating a new file, deleting a file, or formatting the whole disk. Where exactly does it say you can put in a different disk?

4a. If you delete a file from a disk, some of those 1s and 0s get updates. Parity is updated. Whether formatting, writing, or deleting, it's all writes as far as the bits are concerned.

Maybe you're confusing replacing an old disk with a new disk, and just swapping two disks that are already part of the parity calculation. Swapping two disks that are already part of the parity calculation doesn't invalidate parity, though it would invalidate parity2 since the order of the disks is involved in the somewhat more complicated (Q) parity2 calculation. If you need to replace a disk with a larger disk during the conversion process, you should let it rebuild the replacement before proceeding. Doesn't really matter whether the original had files on it, or whether you formatted the original first, a complete rebuild of the replacement would still be needed or you would invalidate parity. I suppose there are other approaches you could use instead of rebuilding the replacement in this scenario if you no longer needed the files from the original, but they would all involve rebuilding parity instead.

You seem to be mixing in some other things here that are not really part of the conversion procedure in the wiki that we are discussing. Pretty much everything you are saying in this particular post does not maintain parity. If you remove a disk without replacing it, parity is invalid since the missing bits from the missing disk were part of parity. If you replace a disk, normally unRAID will rebuild the replacement using the parity calculation. The rebuild will have the exact same contents as the original, and the filesystem of the original is its contents. A replacement/rebuild does maintain parity. Actually, it maintains the replacement data disk so that it agrees with the existing parity. Parity is not written to rebuild a data disk. If you replace a disk and set a new configuration instead of rebuilding, you have invalidated parity since the replacement wasn't rebuilt from parity. Parity still has the calculation from the bits of the original disk, and not the bits of the new (and not rebuilt) disk. So, I guess you could say that you've got it right. You think the scenarios you describe would invalidate parity, and they would.

It's a plugin, not a docker. Very different things.

I use rsync all the time to copy between different filesystems, and between different computers using different operating systems. In fact, copying between different computers is pretty much why rsync exists. The differences between filesystems and operating systems can be pretty significant at the lower levels, but at the file level a file is a file. And if you want to get technical, rather than absolute and relative addresses, maybe we should talk about logical addresses. There is a lot going on at different levels of the system, such as drive firmware.

Check filesystem on disk1 https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems

Lots of "old schoolers" here. Sounds like you understand parity, but you are applying it to wrong set of bits. The exact same address being referred to here refers to the equivalent position on each disk. It has absolutely nothing to do with files, which is the only thing rsync knows about. Don't think about files. Parity is not at all about files. That's why it doesn't matter what the filesystem is, or where files are located. As far as parity is concerned, it is all a bunch of bits. Don't think about the bytes on each disk, think about the bits on all disks. The parity bit at a specific position on the parity disk is calculated based on taking that bit at that same position on each data disk, and adding those bits together, and applying the rule for even parity. (Actually, it just does the XOR of all bits which produces the same result and is more efficient.) This method of parity calculation is similar to what is done with all RAIDs, and even though unRAID is not RAID this is what it does. Parity doesn't contain a parity bit for each byte of each disk. That wouldn't allow it to reconstruct the missing byte from a missing disk since a single parity bit can't tell you much about a missing byte. But a parity bit that corresponds to each bit of all disks allows the bit of any single missing disk to be calculated from the corresponding bits of all the other disks. This is why we say you can only have one missing disk, because all the other disks (not just parity) are required to calculate the missing disks data. Dual parity gives us an additional bit to use so it allows 2 missing disks, but the principle is the same. Think about this and if you think you finally understand how parity is calculated, reread what I posted earlier and see if it makes more sense.

That seems to indicate that you have a user share named "disk 3" rather than a user share named "disk3", but I'm not entirely comfortable with the way the webUI displays this information. Can you go to the command line and try this? ls -lah /mnt/user Please be careful with upper/lower case and spaces when discussing this since they are critical.

Parity doesn't have a filesystem, so it is impossible for there to be any files there.

It doesn't matter whether or not something lands in that exact same spot. In fact it is extremely unlikely that it will. And nothing about any of this requires anything to start or end up at any particular spot. Parity is valid at the beginning of all this. Before anything is written, any particular spot is already reflected in parity. If a particular spot gets written, parity is updated at the corresponding spot. If a particular spot is never written, but somehow the filesystem comes to no longer reference it, such as the file that contained it is deleted, or the disk is formatted, again parity is updated, But remember, everything is a write. Parity is not updated at the spot that didn't get written, it is updated at the spot that corresponds to the filesystem data that was written to perform the delete or format. So, parity is valid to start, and everything that happens is just a write that updates the corresponding parity, so parity remains valid throughout.

Not only is this bad stuff going on, but it is needless and useless stuff going on which will have some effect on performance. And it will quickly fill up your log space, another problem in itself. These are bots. They are ubiquitous and relentless. Don't play here.

I've probably said it before, probably even within the last few pages of this thread, but I thought I would explain why parity remains valid for anybody that might be following along. unRAID parity is realtime. Any time there is a write to any disk in the array, the corresponding parity is recalculated and written at that time. All the moving/copying you do is just writing to the disks, which updates parity. It's obvious that writing a file to a disk is writing, but deleting a file (such as when it is moved to another disk) is really just another write operation. Deleting a file writes the filesystem data that keeps track of files. As you are probably aware, deleting a file doesn't really erase anything, it's just that the filesystem no longer references the data. The final piece of this puzzle is that formatting is also a write operation that updates parity. It writes an empty filesystem to the disk. Nothing is really erased (same as when deleting), just filesystem data is written. Format is faster than deleting all the folders/files though, and of course, the whole point of this exercise is to format to a different filesystem.

One of your disks has a top level folder named disk3 that you accidentally created when trying to move the contents of disk3 to another disk. That top level folder is an "accidental" user share named disk3 because any top level folder on cache or array disks is a user share named for the folder. Under that disk3 folder will be the folders of the "intentional" user shares (the contents from disk3) that you were trying to move from disk3 to that disk. You just need to move those folders up one level so they are top level folders on the disk (which will then make them part of the user shares named for those folders). Then when the disk3 folder is empty you can delete it from that disk. Midnight Commander is a builtin file manager that is easy to learn, just type mc at the command line. I know it was available in unRAID 4.7 so maybe you are familiar with it already. Do you know how to use Midnight Commander?