Squid

From the terminal, mover stop Then under settings, scheduler, mover settings, enable mover logging Then restart mover. After a suitable delay for when you see what you were seeing before, post your diagnostics Downside to appdata on the array is that it's slow access compared to the cache drive and multiple drives will have to stay up and spinning pretty much all the time. I'd either use an unassigned drive or get a bigger cache drive. Personally I'd choose the larger cache or have the shares not set to use the cache drive. I only have my appdata and my downloads share using the cache. Everything else writes directly to the array (use cache: no)

Try editing USE_SSL in /config/ident.cfg from "auto" to instead be "no" and see if that makes a difference (reboot will be required). And if it does, then within the gui change it back to auto in management settings

Via the webUI, you can't. You could however create applicable entries in the smb-extra.cfg file on the flash drive and do whatever you want. Something akin to [sharename] path = /mnt/user/share1/folder/ valid users = tfox carole public = no [othersharename] path = /mnt/user/share1/folder2 valid users = beavis butthead public = no

Try creating another user and log in with those credentials. Not too many people still use FTP

Due to how it works, mover is not particularly efficient in moving files (checking if they're in use etc) This will be magnified especially if you have say Plex installed where any reasonably sized library will result in many thousands of files within the appdata being moved. Not sure though why you want appdata to be moved from the cache drive to the array. "Prefer" is the general setting for the appdata share

I think you keep misquoting /mnt/cache is the cache drive FCP was complaining that you have /mnt/user/cache which is a share (whether or not unRaid filters it out from the shares list), and may or may not be stored on the cache drive ls /mnt/user/cache will show you whats in it rm -rf /mnt/user/cache will delete it.

The exact same problem. And you ultimately solved it by what we're trying to get @Inenting to do. Fix the problem on the template, and then delete the share

If its still there after a rescan, then on the shares tab "cache" is still there and you haven't deleted it yet

No and definitely no The entire complaint from FCP was that you had a share called "cache" That can under certain circumstances mess things up (or at the very least it messes you up )

Now that it's empty you'd be able to click on it in shares and then delete it. cache never shows up in the shares list. The shares that may or may not use the cache drive are listed there.

https://forums.unraid.net/topic/57181-docker-faq/page/2/#comment-566094

Is there anything in the share? Go to shares, then click the little folder at the far right for cache

YMMV depending upon the container Worked for me when I did the command in Binhex-Krusader's console

change USE_DCHP to be "yes" in that file and reboot (or if you can access the webGUI, then you can do this in settings - network settings)

It is (and does). I can easily exceed line speed when moving files from share to share (and if I look at what Windows thinks is going on with the network, no data is being transferred to the desktop) You should be able to more or less hit the same write speed (all else being equal) when doing this via Krusader

#!/bin/sh delay=100 beep -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay beep -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 beep -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay -n -f 493 -l $delay -n -l $delay -f 622 -l $delay -n -f 493 -l $delay -n -l $delay -f 739 -l $delay beep -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 -l $delay -n -f 493 -l $delay -n -l $delay -f 659 -l $delay -n -f 493 -l $delay -n -l $delay -f 783 for i in 1 2 3 4; do beep -f 493 -l $delay -n -l $delay -f 987 -l $delay -n -f 493 -l $delay -n -l $delay -f 880 -l $delay -n -f 493 -l $delay -n -l $delay -f 830 -l $delay -n -f 493 -l $delay -n -l $delay -f 880 -l $delay -n -f 493 -l $delay -n -l $delay -f 830 -l $delay -n -f 493 -l $delay -n -f 739 -l $delay -n -f 493 -l $delay -n -f 830 -l $delay -n -f 493 -l $delay -n -f 659 -l $delay -n -f 493 -l $delay -n -f 739 -l $delay -n -f 492 -l $delay -n -f 622 -l $delay -n -f 493 -l $delay -n -f 659 -l $delay -n -f 493 -l $delay -n -f 622 -l $delay -n -f 493 -l $delay -n -f 659 -l $delay -n -f 493 -l $delay -n -f 622 -l $delay -n -f 493 -l $delay -n -f 659 -l $delay -n -f 493 -l $delay -n -f 622 -l $delay done

Sure, but only 1 can run at a time There's the controlr app for your phone that will allow you to do that. And also I believe a virt-vm manager docker app that you can interface with. And of course if you're so inclined you can always drop down to the shell.

Bottom right on any page will get you there. Click Manual

beep Will have the built-in speaker on the mobo (if there is one) beep once But, note that when I do that within a container it's no where near as loud as when I do it just from unRaid's console Now, if what you're wanting to do is do that on external speakers connected to the 1/8 jack, then what you want is impossible as there are no audio drivers built-in to unRaid

Completely unrelated to your problem, but set the cache drive to never spin down. Since it can't in the first place since it's not a spinner, you only get your log spammed with errors when unRaid tries to spin it down

Completely up to you of course, but I would think that exFat would be part of the base package since it's the default format for flash drives > 32G

@dlandon, Just a comment regarding UD+ If you have UD up to date, and then decide that you need UD+ and install it, everything works good. But then you're cleaning up stuff and notice that UD is still sitting in the plugins tab and uninstall it. Now you've trashed the install of UD+, and a reboot or an uninstall / reinstall is required. Since the two plugins are effectively mutually exclusive, why not just have them with the same filename on the .plg Would solve a ton of problems (such as the unlikely event where UD gets an update, but UD+ does not which would then trash UD+, or if they both have an update and the user updates UD+ and then UD) While I'm not a fan of duplicating .plg filenames, in this case it really makes sense and is the only workable solution EDIT: Nevermind They aren't mutually exclusive My Bad

Yeah, I'm not a fan of that UI design choice, as it took me forever to find it also the first time

Enable destructive mode in UD's Settings

Because I typoed them (too many 2's) 208.67.220.220 & 208.67.222.222