Squid

Bug due to the .com Try the update New test as of today. Also like everything else in FCP (especially warnings), there is no black and white, but rather all of the tests are "grey areas" and guidelines. If everything works then feel free to ignore.

Initially I'd so no

That's how the SWAG app and MyServers fundamentally work. Not a networking guy, so will leave it to others with regards to the certificate etc. Only give them access to the paths with the minimum required access necessary. IE: No need for Plex to have any access to your banking info. Plex as an example doesn't necessarily need write access to any of the shares either.

You've got an empty device in the template. Remove it. --device='' What this means to to actually hit the remove button, not simply blank it out

Hitachi_HDS722020ALA330 Power on hours 91041 (10y, 4m, 18d, 9h) 0 reallocated sectors. Luckily its from before WD's acquisition so it's actually a decent drive.

Is this transferring to the array or to the cache? The way the system works (and it's most noticeable when going to the array) is that transfers get cached in RAM and slowly written to the drive. Eventually you get to the point where RAM is full and the system is waiting to clear it out a bit by actually writing it to the drive. Generally, to the array, on average you're looking at roughly say 60MB/s sustained. The "pauses" aren't particularly important as what you're basically looking at is the average speed for the entire transfer or the total time it takes). You can speed up this by enabling reconstruct write in Settings - Disk Settings which speeds up writes at the expense of power (all drives have to be spinning) Directly to a cache drive (particularly SSD) these dips are massively diminished due to the faster writes to it

if you haven't rebooted yet, then (ctrl-c to break out of the diagnostics script) cp /var/log/syslog /boot/syslog Powerdown powerdown (this will initiate a clean powerdown) pull the flash and upload the syslog file now stored in the root here and then reinsert and fire up the server

(Or switch the line ending format with the config file editor plugin)

What are you actually talking about?

Remove the historical devices from UD. If that fails, post in the UD thread with your diagnostics

What will "break" is during an update to the container if the template also has changes then the update process will not pick up any changes. Since template updates are rare this isn't a huge deal Fix Common Problems will complain and inform everyone that the URL has changed and will prompt the installed user base to click a button to automatically update the URL (which fixes the above)

Sure, a better overview could have been included (and in the read me first) but an additional tag and flag for Apps has recently been introduced to explicitly state additional requirements but until the release of Unraid 6.10 stable it won't wind up being utilized commonly. But I'm adding it manually to highlight that you need Redis and PostGres installed

Can you still reach the webGUI from another system? Post your diagnostics

Dec 31 09:54:14 Tower unassigned.devices: Error: Device '172.27.9.81:/mnt/Skywalker/bkup' mount point '172.27.9.81_bkup' - name is reserved, used in the array or by an unassigned device.

You can probably manually add additional shares via editing the smb-extra.conf file on the flash drive appropriately [UDFOLDER] path=/mnt/disks/whateverdrivehere/UDFOLDER valid users = andrew write list = andrew

See if you can't set it to Hard Drive, and in the Hard Drive boot priorities set it to the USB flash device

If there's no path mapping for /tmp in the Plex template, then it's transcoding directly to RAM within the container which has no upper limit on it's size. If you've got it mapped to say /tmp/plex on the host then it has a 50% upper limit of memory. Either way it would appear that Plex isn't clearing out the files and you should probably post in the applicable Plex thread to get more suggestions from other users who are heavy Plex users.

Which share

The CPU isn't running anywhere near what the dashboard says, but rather it appears that you continually are having processes killed off due to out of memory issues and the dashboard can't make head or tails of what the current situation is. Looks like you've allocated ~3Gig to the Windows VM, but try and look at all of the docker apps. Are they storing stuff in memory that they shouldn't be? If you stop Plex does the memory issue immediately disappear?

The % is nothing as it's only a core and a half on a 20 core system. On your diagnostics originally posted, It looks like your currently running a parity check Dec 27 11:20:27 Truffle emhttpd: unclean shutdown detected 65% CPU usage A home assistant VM 200% usage SHFS is taking 126% Ubuntu VM 47% NZBGet is currently unpacking something 54% Plex is running @54% A trim is currently in operation 21% ********** And you have a tab sitting on the docker page in advanced view - 12% Tautulli, Sonarr, Ombi etc are also all taking ~20% each So, there's nothing out of the ordinary at all in terms of CPU usage. But, as noted this is IOWAIT Now, you're running a trim operation on the filesystem every hour. This is extreme. You only need to run it say weekly and only during times when nothing else is going on. While a trim is in operation the system will massively compete for IO time to the SSD's, and when trim has the CPU cycles, nothing else is allowed at all to utilize the IO to any device There average time it is taking to do the trims across all the supported filesystems / devices is ~4 minutes. But, with the perfect storm you've got at the moment its been running for 13 minutes on just the first device it finds (since nothing has been logged yet), so responsiveness is horrendous As an aside, the best way in my opinion to look at IO wait is via the NetData container as you'll be able to see it graphed nicely over time Set your trim frequency to be something sane.

Post your diagnostics. And for giggles, a screenshot of Settings - Management Access

Based on the screenshot sans any further information, it would appear that Plex is transcoding via the CPU, and maxing out the cores is what you should expect to see. You should post the diagnostics when it's in this situation

SSH requires a root password to be set

You would also need to post your diagnostics to correlate what happened

It's because you're passing through a single mount point of either /mnt or /mnt/user mapped to say /UNRAID What you seeing is normal and to be expected in that situation. Have radarr/sonarr move them into the appropriate share set to use cache:yes and mover will take care of the rest.