Squid

But if you already have the power down plugin, why is the script plugin involved? Not that big a deal to handle (and then you basically will have a GUI to handle something you would normally have to do via the command line to do it with the powerdown functions) Will add in array start and array stop to the frequency options. Should take about 10 minutes for me tonight....

And that's my bitch. Stupid design, but not your problem.

Already does. Depending upon your settings, it tries to write to either every disk or to only the disks that are spun up. It may also catch on spun down disks when it doesn't try to write to it that its been mounted as RO, as I check the file system status, but since the particular file (disks.ini) is not included in diagnostics, I can't verify that a RO mounted filesystem is tagged within disks.ini

Nah, my problem is with Calibre itself. It won't let me create a database within my existing ebook folder, and insists on an empty folder, and then proceeds to ultimately copy all of the books from my master folder to its library location. Like I said, not strictly your problem, but a calibre one. Just an annoyance with the way that calibre works. I'm just going to rearrange my organization to reflect this fact of life. Beyond that, I much prefer COPS to Ubooquity.

Works great. Thanks for this CHBMB et al The only thing I'm wondering (too lazy to do a websearch) (and admittedly not strictly relevant to this app) is how can I set up a calibre library without it copying the ebooks over to the /config folder

That's pretty paranoid. The likelihood of of two of your files having a hash collision with blake2 is astronomical. Why? Regardless of whether you see it or not, it is entirely possible (likely even depending upon the number of files) of 2 completely different files having identical hashes. Using a 32bit hash (admittedly Blake2 isn't), the odds of a collision is 1 in 2 for 77000 files. Hash values are by definition not unique -> if they were, your bluray rip would take up a whopping 64 bytes on your hard drive. When 2 file's hash values (regardless of length) differ, its guaranteed that the files are different. When 2 file's hash values are identical, the only way to determine that the files are different is to perform a byte-by-byte comparison. Hashing is used to identify is a transfer of a file (or the integrity of a file) was performed successfully, because small changes in the file will produce large changes in the hash. They are not intended to compare the contents of two different files. The odds of a collision with Blake2 on a single file that has suffered silent corruption (ie: the original file and the corrupted file both having the same hash) however is indeed astronomical. And that's what makes Blake a great hashing algorithm.

Since your usage case has items going to a UD mounted device, upgrading to 6.2 would be worthwhile, since the limitation of having to stop the docker service and then restart it is no longer necessary if you use one of the "slave" modes when setting up the paths.

Because every time the array starts, this plugin will perform the tests, regardless of if a schedule is set or not. Didn't look at the logs, but the delay shouldn't be more than say 10 seconds tops.

With sleep, another computer can power up the server when it needs it I use WOL from fully shut down on a regular basis. Not all mobo's support that.

With sleep, another computer can power up the server when it needs it

Stop the array then from main click disk 1 and change the format from auto or reiser to xfs. Start the array and you'll be prompted to format the drive. Then you can copy disk2 over to it. Repeat Sent from my LG-D852 using Tapatalk

I decided after reading RobJ's post that I would worry about drive slot assignment after the drives were converted to XFS. The one thing he doesn't cover is what happens to the parity drive. Does it just stay RFS forever? Does it matter? The parity drive doesn't have a file system at all, so nothing you need to do with it.

The work around was to not have CA download the appfeed, but rather you supply it yourself (assuming that you could d/l or transfer it via other means). Only 2 lines of code to add. Just can't remember exactly if that would have helped you out or not. Nothing I can do about the actual downloads from dockerHub / gitHub

Folders starting with a period are hidden in Windows explorer by default. Why are you using .appdata? I only do so because I.... actually I can't remember why I did, but it must have made sense once upon a time... Because at one point that was a workaround to prevent mover from moving the files off of the cache drive. No point in it now however...

Permissions on the various files in appdata are basically going to mean that you might have no choice but to drop down to the command line and edit the files with nano But, while I'm not familiar with sickRage (familiar with sonarr), I don't see why you would ever need to manually configure the files beyond very advanced usage settings.

From the Community Applications plugin Link in sig

Added in the ability to flag / pin any app for future viewing. Hitting the https://github.com/Squidly271/community.applications/raw/master/source/community.applications/usr/local/emhttp/plugins/community.applications/images/redButton.png[/img] will pin the app, and https://github.com/Squidly271/community.applications/raw/master/source/community.applications/usr/local/emhttp/plugins/community.applications/images/greenButton.png[/img] will un-pin it. CHBMB: That's what it originally was. I think it's fair to say that it has suffered somewhat from 'feature bloat' Joking aside, I wouldn't use Unraid without it, it's essential. Sent from my LG-H815 using Tapatalk where do I stand on this graph:

I'm not seeing where I can change the AppData Config Path mount to be mounted RW:Slave, there's no edit button like there is for all the other mounts. Am I blind? Is it relatively safe to ignore this? I can't find much info on what the ramifications of RW vs. RW:Slave are. Edit the container, then edit the path. Its there. Without using one of the slave modes, every time you restart the server, you will have to stop and start the entire docker service for the app to see any files within a UD mounted share.

Why not just change the /config mapping to point to some folder on the array? Of course you'd need to move it all there too. I have considered that but I would like to keep the core software on the SSD if possible. what version of unRaid. Symlink (and more to the point hardlink) support on user shares isn't supported on 6.1.x and only works on 6.2RC3+ It should work however by using a disk share Also, the core software is stored within the docker.img file, not within appdata Still on 6.1.x Maybe it is just easier to install it on a share off the cache then. Thanks for the info You'll have to use a disk share, not a user share. IE: set /config to be something like /mnt/disk1/appdata/Plex and not /mnt/user/appdata/Plex. Plex makes very extensive use of hardlinks which are incompatible with /mnt/user/... on 6.1.x Okay I might give that a try! But be aware that performance of the app as a whole (and transcoding in particular) is going to go downhill with appdata sitting on the array. If you really make extensive use of Plex, your best solution is to either turn off thumbnail generation (which will save huge amounts of storage space, but you'll probably have to start the db over again from scratch to get rid of the existing thumbnails) or a larger cache drive.

Why not just change the /config mapping to point to some folder on the array? Of course you'd need to move it all there too. I have considered that but I would like to keep the core software on the SSD if possible. what version of unRaid. Symlink (and more to the point hardlink) support on user shares isn't supported on 6.1.x and only works on 6.2RC3+ It should work however by using a disk share Also, the core software is stored within the docker.img file, not within appdata Still on 6.1.x Maybe it is just easier to install it on a share off the cache then. Thanks for the info You'll have to use a disk share, not a user share. IE: set /config to be something like /mnt/disk1/appdata/Plex and not /mnt/user/appdata/Plex. Plex makes very extensive use of hardlinks which are incompatible with /mnt/user/... on 6.1.x

Why not just change the /config mapping to point to some folder on the array? Of course you'd need to move it all there too. I have considered that but I would like to keep the core software on the SSD if possible. what version of unRaid. Symlink (and more to the point hardlink) support on user shares isn't supported on 6.1.x and only works on 6.2RC3+ It should work however by using a disk share Also, the core software is stored within the docker.img file, not within appdata

Are you still having problems with this? Popped into my head an easy fix (on my end) to work around this issue.

Then set it to /mnt/disk1/appdata (or whatever disk you want it to be on). Gitlab's appdata currently uses some features that are not available on a user share, but will work on a disk share

Rather than do all the debugging on a simple little script, I modified the instructions on how to disable mover by making a one character change on the config/share.cfg file on the flash drive.

Only thing I can see that is >> user are my volume mappings for media shares in Plex. I did not get this warning with 6.1.9. Wrong thread... But, the first "error" probably says default docker appdata location. Its adjustable within settings - docker, and wouldn't have done anything on 6.1 since that option didn't exist. The dynamix scsi thing is all because bonienl has as of yet not published it to CA (probably because it may be a WIP). That warning is basically to stop people from running 6.0 plugins, etc since CA only has 6.1+ compatible plugins I wish you kids wouldn't squabble like that. May need to be whitelisted? I am unable to change the path to a /cache/ path. the helpful drop down only shows User shares. I put in the path manually and saved and it claims the path doesn't exist. See Screen. [FIXED] by deleting and recreating docker.img Once unRaid hits the next RC (or final), I'm probably going to be removing that test if you're on 6.2 because hardlinks *should* work on user shares.