Terebi

@Reynald I don't know if you have seen it, but I made a script for mover tuning to do enhanced age based caching that may be useful as a place to steal some ideas from.

Its probably doable, but since the two values are mostly equivalent (unless appdata grows suddenly) it doesn't matter enough to me to fix

in a console if you just run mover, you can see if it triggers my script or not

Every time my script runs it should create the file. Perhaps the script is not in the same location the mover tuner setting is looking for it in? Or the permissions on the script may need to be fixed?

It certainly might be possible to expand my script to include recently read item into things to preserve on cache, more than just things that were added recently. For my purposes, recently added and recently viewed overlap a lot though, so it might not be as useful as imagined. And without more complicated work would not handle promoting things from the array to the cache.

Im not sure I understand what you are saying. When you stop the array, the file gets uploaded? Then something else (not in unraid) deletes that file after an hour? and if the file is still there at start, it autostarts?

It depends on what threat model you are worried about. A random robber probably isn't looking for your unraid server. And they also probably don't care about your media or whatever else you have on it either. If you are a prolific pirate, hacker, or some other kind of criminal worth busting, the authorities are going to take your drives, and probably also your router. In the US at least, in 99% of circumstances you cannot be forced to turn over a password that is in your head. You CAN be forced to turn over any hardware. And destroying or deleting from your hardware if they for some reason left it behind, is itself a crime. Similarly in a lawsuit they can subpoena all the hardware, and having the key on your router suddenly be gone will put you in contempt and possibly lose whatever case you have. Your unraid box is still accessible via vpn or whatever even if the array is stopped. My machine reboots once every few months. 99% of the time I rebooted it on purpose for an upgrade or because I'm tinkering with it for some reason. Unexpected reboots are like 1/x a year, for a power outage or something. Having the array be down until I can remote in and type in the password once a year, is well worth the additional security.

How does this work as SSD only when unraid requires an array disk, and the TRIM issue?

Are you sure you have the second setting set to ignore things named in the file?

Easier and more secure to just TOTP. Just add it to your 2 factor app of choice and you are done. This of course only protects the login page from remote users. Anyone with physical access has the keys to the kingdom. And if there is a vulnerability in the web UI that could bypass any security implemented. A simple implementation of this could be implemented in an hour or two probably. Just a screen for the setup, and some setting on the USB for the time seed.

The instructions to get to the FTP including hostname, username, and password, would need to be on the USB for that to work. So anyone who has your USB can also go do those things, unless there are firewalls in the way of the FTP Depending on who you are worried about, where that FTP is, how it itself is protected, that again may reduce effective security to zero.

Comment necromancy, but TVs are an easy to point to example. Lots of TVs only include 100megabit ethernet connections, which cannot support 4k remuxes etc, so you have to fall back to wireless!

"secure" and "automatic" are mutually exclusive unless you don't care about wide swaths of "secure" to the point that you shouldn't bother. Disk encryption protects against someone having physical access to your disks. In order to automatically decrypt the disks, the encryption key would need to be on your USB, or somewhere your USB can access. Anyone who has access to your disks also has access to your USB. Therefore the encryption is providing little to no value. There are some scripts that can improve this situation, by downloading the key at boot, but that means the key is sitting somewhere to be downloaded from. Depending on where that location is, and what kind of threat you are protecting against it may reduce effective security down to zeroish.

Security is not really unraids strong suit, almost everything in the system is running as root. The text file will go where ever the output directory is set in the script. You just have to point mover tuners ignore file to the same file/path

My script itself is safe to run if something is seeding. But the regular problems the mover has if something is seeding are still applicable. My script helps with this problem, because it will tend to extend how long a file lives on the cache, which will reduce the frequency of a torrent being actively seeded by the time the files get moved to array. The biggest problem is if you have the torrents hardlinked (from radarr/sonarr), because if that file is one that should be moved based on time/threshhold the "plex" copy will be able to be moved, but the torrent copy might not move it the file is in use. That will break the hardlink and cause space duplication. If you aren't using hardlinks, then it probalby doesn't matter, because if the torrent fails to move it will just retry it the next day. Because of this, its probably safest to continue to pause/resume torrents as part of the mover process, even though it may work ok 9/10 times. You may need to modify my script to add in the code to pause torrents, because I think the tuner setting used to enable my script is the same setting used to pause torrents.

The binhex apps run arch, and do not have SSH running, so are not exploitable even if you have the bad versions. . Just wait for the next version of the binhex images to come out.

Even given 2fa you should probably still use VPN. The risk of someone brute forcing your u/p is probably not as big of a concern as some unknown vulnerability that just bypasses login all together.

Adding the parity drive first will be faster. If you add parity second, it will have to read all of the new drives to calculate its parity. If you add the drives second, they can be individually zeroed without affecting parity.

The file will get recreated from scratch every time mover runs, so you can't really edit it to control what happens. In the first post I give a command that lets you manually move a file/directory immediately. It doesn't "delete" oldest files really, because it recreates the file from scratch every time. But that is the effect. Files will be added newest to oldest until the size is reached, and then the oldest files won't be added to the file again. Then the mover will run, and since those oldest files aren't listed, they will be moved.

Yeah, the purpose of the script is so you can ignore this and it self manages based on time. But I admit I do manually move things off of cache that I know won't get watched soon/frequently to make room for other things to stay on cache longer

You don't need to recreate the file. In notepad++ you can see the line endings (see the LFs in my file) You can then convert using notepad++ too in the edit menu.

It looks like you saved the file with Windows line endings. (\n\r). It needs to have linux endings (\n). Some more advanced text editors (notepad++) can convert line endings for you. Or there are various linux command lines you could google to do the replacements.

You do not need an end slash in the output dir. You can see in the next line (output file) that a slash is added there between the directory and filename. The file should be created every time mover runs. Otherwise the mover would move anything not listed in the file. You can run the moverignore script manually to make sure the file gets generated by going into the directory in a shell in the sh file is in, then running "bash moverignore.sh" . If you still have the movertuning threshholds in place for size and age, then mover may not be running at all, which would mean my script would also not run.

you can run the moverignore script manually before the mover runs, to generate the file and make sure it appears as you expect. Instructions for doing so are in the first post.

If thats what the output directory is set to, yes