trurl

After fumbling around a bit with moderation on the new platform, I have merged the topic. I agree it should have been here in the first place instead of "Storage Devices and Controllers".

Those details would be up to your specific configuration. For example, I let all disks participate in user shares (global), but for each user share I only include specific disks. Different people set these things up differently and for their own reasons, not always good ones. The main thing to remember about user shares is each user share's settings really only controls where things get written. Any disk which has files for the user share (top level folder) will be included for reads of the share, unless excluded globally from all user shares.

That sounds like a good approach. Maybe one that nobody else has thought of because nobody has a cache disk that large. You could even get your dockers working with this "yuge" cache if you wanted, using the replace cache method I linked before. That way you would still have your apps while going through the lengthy process of converting the other drives. Then replace cache again when done and use it for parity as planned. I like it!

I don't think you can access a GPU for this from docker anyway.

I would say you need some more details in your plan of attack. The wiki never mentions using another server for reformatting and copying, and not just because many people don't have one. Moving disks between servers will invalidate parity. Unless you have a really good idea what you're doing and have a very detailed and specific approach in mind, moving disks from one server to another is going to invalidate parity in both. And moving the disks back with files on them is going to invalidate parity in both no matter what you do. Even if you don't care anything about parity on the test server you are still going to invalidate parity on your main server moving disks back and forth. Do you understand how parity works? What I say here is pretty obvious if you do understand parity.

I can't imagine where you read this, but it isn't correct. When moving and copying between disks or between systems it doesn't matter about the filesystem since those operations are only concerned with files and folders. If you copy a file from your unRAID to your Windows you don't worry about this, right? You could do it that way, but you can get unRAID to do most of the work for you by following this wiki, except at step 6 you would just stop the array and skip to step 9 since you aren't replacing the disk.

Not really obsolete. This was recently discussed starting here, with the result that it was added to the FAQ.

One comment on that though - I was examining the diagnostics here (no obvious issue, but other interesting things), and noticed an example of what happens with the common advice given to use /mnt/user/system for docker.img and libvirt.img. In their syslog, every day, the Mover tries to move /mnt/user/system to the Cache drive, and it may have succeeded with the rest of the files in the system share, but can't move docker.img and libvirt.img because they are always in use. And it's not going to be able to, unless the VM's and dockers are stopped while the array is up. I don't know what other files exist in the system share, but it doesn't seem to me to be a good idea for it to be split up like that, part on the Cache drive and part on Disk 1 (part slower, part faster; part fault tolerant, part not; parts that go together split up). It does work though. I realize Tom did it this way for the general user case, as /mnt/user/system works for everyone, with or without a Cache drive. But if you know you have a Cache drive, it seems more optimal (to me) to set the paths to be /mnt/cache/system and /mnt/cache/appdata, and place the Docker and VM files there (preferably it's one or more SSD's). Plus, it's one less indirection in the data path, no FUSE involvement (most users won't care about that). What a user should do if they add cache after these cache-prefer shares are created is manually run mover with the VMs and docker service stopped. Just another thing that is obvious to some of us but won't be considered by many without more documentation (which some will not read anyway).

It appears that you are using rsync in the script. UD has no control over what rsync is doing. You might find an rsync parameter that would respect the special characters in your file names or a way to display them in their original form. I also found that Windows couldn't handle these characters in filenames either. That may just be something to do with my locale settings. Since it only affects a few files now and then (mostly downloads where someone else created the filename), I just rename the files.

This is the commandls -l /var/log/packages/inotify-tools-3.14-x86_64-1 and this is the expected result -rw-r--r-- 1 root root 1418 Feb 16 23:00 /var/log/packages/inotify-tools-3.14-x86_64-1

Sounds more like a question for the plex forums than the unRAID forums. Do you not know which plex docker you are running? This is the support thread for linuxserver.io plex docker. Unlikely the unRAID upgrade has anything to do with this either.

The function needs to remain, but it could do with a renaming. I purposely have shares that I keep data manually switched between fast SSD cache and slower array disks, based on usage. I need that share to write new files to the cache drive, since fresh files are typically referenced frequently for a while. As the data ages, I manually move it to the array folders so it's still available, but not high priority. An automatic version of what I manually do has been discussed in the past. Hadn't considered that. An excellent adaptation of a builtin feature. There has always been some confusion with the Use cache feature, and it perhaps got even more confusing when Prefer was implemented. I like the current functionality with the 4 choices, but even if you spelled out exactly what the 4 choices do in the webUI I think some users would still be confused unless you went to a lot more trouble to discuss possible scenarios for each as you have done here for cache-only.

No it doesn't (and this posting should be in the CA thread) - just tried deluge vpn and it does indeed bring up the template for deluge vpn Sorry for posting in the wrong place. It is solved, just rebooted and everything is working fine. I cleaned up your mess. Sorry Squid, it's all in your thread now. The internet rule against crossposting has been around since before the World Wide Web. There is at least one very good reason for this rule. Often times, people will go to considerable trouble to do research and spend some considerable time writing a post to help someone with a question. Not realizing that some other person has already done the same because the person who asked the question posted it in more than one place. Don't waste our time by crossposting.

Don't know what you're seeing in your Installed Apps, but as shown by your previous post you are running limetech plex: Perhaps you have more than one installed but only one running. Go read the Docker FAQ in the Docker Engine subforum. It will tell you how to fix your "layers from manifest". Then when you reinstall, I recommend you do install the linuxserver.io plex instead of the limetech. And then if you still have issues, post your docker run command as described in the Docker FAQ.

Looks great! You should add that to the FAQ +1

Prefer is a recently added setting, Only could probably be done away with now. With it set to Prefer, to get all your appdata back on cache you can run mover yourself instead of waiting on its scheduled run. Main - Array Operation - Move now.

It uses inotify to let it know when a file is new or modified so it can hash them. Turn on Help for more instructions on how to get the old files hashed.

What did you set it to? You really should set it to prefer since your previous setting may have moved your appdata from the cache disk, and prefer will move it back where it belongs.

How large are these? Might be simpler just to replace with SSDs and add them to your regular cache pool. Sometimes it's better in the long run to just spend money. I used a 10K drive as cache (because I already had it) when I built my first unRAID but decided it was too noisy and quickly replaced it with SSD. That was back on unRAID 4.7

Possibly a corrupt flash drive. Put it in your PC and let it checkdisk.

unRAID won't clear a new parity drive. There is no need for it to be clear since it will be completely overwritten by the parity sync. So if you want to test your new parity drive you may want to preclear it anyway. And, when replacing a parity drive and adding the old parity as a new data disk, you don't really need to clear the old parity/new data disk. You can just follow bjp999's method.

I don't think so.

Are you sure you have posted to the right thread?

That is correct. You don't have an absolute path to the container volume Movies. Put a slash (/) in front of it. Also, the volume mappings you have specified here don't match the ones you had in your earlier post. You are missing your tv volume mapping, and you have changed the case of the movies volume mapping. So, it seems pretty confusing what you are doing at this point. Are you sure you chose the correct "my-plex" template?

Well, as I said, if you were trying to update the plex application, you should just restart the container, not update it. The LSIO plex docker checks for the plex update when it starts and downloads the new version if necessary.