Squid

Edge case - CA doesn't enforce blacklisting on Previous Apps just in case you need / want to reinstall it for whatever reason. It will never allow you to install it from the available apps though....

Re-read your post, and totally missed where you said no SSD or cache. Yeah, can you give me your diagnostics... thx EDIT: my bad. My secondary server (which also has no cache drive) passed the tests because for some unknown reason I had SSD Trim installed (no clue why I would!?!) Fixed...

Nope.. It is exactly what it says it is. Your performance is going to go downhill because your SSD cache drive won't trim itself. Install Dynamix SSD Trim via the apps tab.

Update FCP... I removed that test a couple of versions ago

Post is about sonarr / nzbget, but the same discussion applies.

Restart Sent from my LG-D852 using Tapatalk

do a powerdown -r from the command prompt if it doesn't do anything, then umount the docker img via the command I gave above and try it again...

The path to the docker image.... ie: /mnt/user/docker.img or /mnt/user/appdata/docker.img, etc To stop the array (at least pre 6.3.2:) wget -qO /dev/null http://localhost:$(lsof -nPc emhttp | grep -Po 'TCP[^\d]*\K\d+')/update.htm?cmdStop=Stop Not sure if they work with 6.3.3 and the csrf security though

Can you post your diagnostics

what I would do (in conjunction with the question on the other thread) SSH: powerdown After a couple of minutes if it still hasn't shutdown, then ls /mnt Either all the disks are still there, or only the cache drive is still there Probably the docker.img is stopping a powerdown / shutdown. umount /mnt/user/{WHATEVER}/docker.img Hopefully the shutdown will now continue.

Yes. Once a bread error occurs, the "boot" flash does not exist anymore, and nothing you can do to bring it back short of a reboot. IE: the flash drive dropped offline (either due to a flash problem or controller (hence why I suggest USB3<-->USB2)), and when it came back it was assigned a different drive letter.

Because of this...

Yes... But, whenever "bread" errors happen it means that unRaid lost track of the flash drive. Net result is that when you plug it back in, if you try and change a setting on the UI that requires a write to the flash, it will fail and be like nothing happened. More noticeably, when you reboot, you will have a parity check happen because the flag that gets set on the flash to indicate a clean shutdown can't get written. My personal opinion is that this is going to wind up being a port thing rather than a stick issue. If its plugged into a USB 3, plug it into a USB 2 (or vice versa)

Except that I was just thinking that a typewriter does a lfcr whereas windows does crlf. Did Microsoft get it wrong?

Update 2 of 3 to overhaul the UI for CA. This one removes the less commonly used buttons (view modes, sort orders) from the display and instead moves them to a hover / click popup. The system does default to this new UI, but within Settings (Community Applications Section), General Settings you do have the option of downgrading the system back to the old UI. This may be necessary to be done with some mobile devices (I have a mobile phone that won't interact with the new buttons) New UI is only available on 6.3.3+

( ^ in case you don't know what cr/lf mean) - Various improvements in the UI and error handling - Fixed: Preserve Linux or DOS style line endings when saving by default (previously, would save everything in linux format regardless of the source format) - Added: Ability to switch between Linux or DOS style line endings

Easier doing the user scripts within the plugin itself. No drilling req.

Oops. You are correct there. (don't know what I was thinking, nor what @kizer was thinking). On the flash drive, edit /config/disk.cfg (notepad will do just fine) and remove the comments from these lines: diskComment.1="Read Only Mode. Restore normal settings via <a href='/Settings/Ransomware'>Ransomware Protection Settings</a>" (There will be an entry for each disk)

Should be available within Community Applications sometime tonight after I verify basic functionality, etc....

-reserved-

CA Config Editor A simple plugin to allow you to easily edit any of unRaid's configuration files (or actually any file on your server) within your browser without having to go to the command line. (including syslinux.cfg) While most of unRaid's settings are available to be modified within its webUI, there are some cases where it is required / desired to manually edit them. This plugin will allow you to do that. Backups of files edited are automatically created (filename.bak), and can be restored by copying from the backup window. Additionally, any file present on your server in any folder can also be edited beyond the .cfg files that shortcuts are available for. This is helpful for when a docker application requires you to make some changes within its config files in the appdata folder, but either permissions prevent you from doing this over the network, or you're not familiar with the command line. The usual warnings apply: Changes to the configuration files could have unintended results if you enter in wrong values. Install it via the Apps Tab (where else?). Either go to the CA Modules section, or search for Config and scroll down to CA Config Editor. Once installed, you can find the plugin within the Tools tab.

It makes sense if the apps work by scanning the folders on a schedule looking for completed downloads (aka: blackhole) instead of sitting there waiting for the dl client to tell them the dl is complete.

Well, its fixed now... Absolutely zero clue what was going on, as what you're describing should be impossible, and I can't replicate it using your exact config files... Settings - Notification settings.

@trurl, @tunetyme I ran those .cfg files through FCP, (and made the appropriate folder within /mnt/user), and it doesn't generate anything at all. Nor should it, because there is nothing wrong with the setting. The initial post stated "... recently updated updated from 4.7 to 6.3.3" My guess is that the errors were indeed valid with the initial configs of the shares. And FCP caught that. At some point you went in and changed a setting or what not within the shares and that has corrected the error (I know this happened, because shareFruit and shareCOW is part of the configs which is definitely not part of 4.7 / 5.x ) Some of the confusion may arise from how FCP works. After errors are detected, those errors will continually display within FCP until a rescan or a reboot or performed (to aid you in fixing the problems). I would guess that if you went back into FCP and rescanned then you would not see those two errors anymore.

Interesting. Those are definitely from the flash drive and not the diagnostics zip file? And you haven't made any adjustments to the share settings?