Squid

Veto'ing files slows all access down as samba has to then compare every single file against the veto list https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#VETOFILES:~:text=valid %3D yes-,veto,-files (S) fruit:metadata being set to stream is technically faster in conjunction with everything else listed there, but pre-existing metadata may get lost by changing it from the default of netdata. My testing on a directory with ~1000 folders has stream being ~1 second faster to open and populate. Default of netdata was ~2-3 seconds. 6.12.8 has for the settings with Mac Interoperability enabled what LT recommends. Not to say that there may not be better / faster, but the possibility of losing metadata - especially if you ever used AFP on the server dictates a more conservative setting for the OS defaults

The dashboard takes into consideration I/O wait on its graphs

The flash drive is returning some weird errors Feb 24 04:45:35 Server-HP kernel: usb 1-1.1: reset high-speed USB device number 3 using ehci-pci Feb 24 04:45:35 Server-HP kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=30s Feb 24 04:45:35 Server-HP kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 7c a8 28 00 00 f0 00 Feb 24 04:45:35 Server-HP kernel: I/O error, dev sda, sector 8169512 op 0x0:(READ) flags 0x84700 phys_seg 2 prio class 2 Feb 24 04:45:35 Server-HP kernel: usb 1-1.1: reset high-speed USB device number 3 using ehci-pci Feb 24 04:45:35 Server-HP kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s Feb 24 04:45:35 Server-HP kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 7c b0 28 00 00 f0 00 Feb 24 04:45:35 Server-HP kernel: I/O error, dev sda, sector 8171560 op 0x0:(READ) flags 0x84700 phys_seg 2 prio class 2 Which makes it look like a bad flash. Try reseating it and booting again or transfer it to a new device (your data is all safe) You can also try from the command prompt entering in slim and seeing if that brings up the GUI on the local monitor Also, does it work if you boot up in safe mode?

Drives get redballed when a write to it fails. Since this did happen and/or a write to the emulated drive happened while the disk was missing, the contents between the emulated and the physical drive do differ, if only slightly. I always recommend to let the drive be rebuilt so that everything is all in sync. BUT, to do it without rebuilding you would do a Tools, New Config, keep all of the assignments and when starting the array check off that Parity is already valid. But you should really after that do an immediate parity check to make sure everything is back synced together. IE: Best bet is to simply rebuild onto the drive itself.

Looks like its working. Highwater will fill all the 16s up to 8tb freespace. After that's done, then it starts back over at disk 1 and fills every drive up to 4tb freespace in turn. Then starting back at disk 1 it'll go to 2tb. IE: Highwater is based upon the largest drive in the array (50%, 25%,...) not 50%, 25% of every drive. Based upon your drive free space, it should still be on #1

The SelfHosters guys still publish a Chevereto free which installs https://hub.docker.com/r/nmtan/chevereto Your best bet would be to talk to @Roxedus over on their discord https://discord.com/invite/qWPbc8R and get them to switch the repository or add a new template for Unraid

What's your docker run command. Plex would have no idea if the other server is connected via SMB or direct so long as you're mapping the remote server via the template, and adding that path to the library. I've done this for years and never an issue.

Which Unraid version. A number of fixes related to TM support have been done on the latest OS release

So you have it checking for an update every minute from 8 minutes after til 15 minutes after every hour of every day? So potentially if the check / installs happen to take longer than 60 seconds you potentially have it running 8 times concurrently

appdata shareUseCache="only" # Share exists on cache, disk1 a-----e shareUseCache="no" # Share does not exist b-----s shareUseCache="no" # Share exists on disk1 c------e shareUseCache="no" # Share does not exist d--a shareUseCache="yes" # Share exists on cache, disk1, disk2 d-z shareUseCache="no" # Share exists on disk1 domains shareUseCache="prefer" # Share exists on cache isos shareUseCache="yes" # Share exists on disk1 l--s shareUseCache="no" # Share exists on disk1 m---a shareUseCache="no" # Share does not exist n-------d shareUseCache="no" # Share exists on disk1 p------l shareUseCache="yes" # Share exists on cache, disk1 system shareUseCache="prefer" # Share exists on cache You need to stop the docker service (Settings, Docker) Then from shares change appdata to have the primary storage to be cache, secondary storage to be array, and mover action to be array -> cache After applying, from Main, Array Operations hit Move. After mover is finished (may take a bit) then you can re-enable the docker service in Settings, Docker. The share settings are probably what you want anyways.

Does anything change if you select one of the safe modes from the boot menu

Looks like you're using a USB HDD for your parity drive. Many USB bridges do not pass through certain ATA commands to the drives, and this is likely your problem (and you're also not going to wind up seeing any SMART data for the drive either)

From Main, Go to Boot Device, then click on Flash followed by Syslinux Configuration In the section that has the radio button selected (ie: your default boot mode), add in to the append section pci=noaer The section will wind up looking like this (assuming the default non-gui boot mode) kernel /bzimage append initrd=/bzroot pci=noaer Don't remove anything else that you may have added yourself (or was added in via another setting in the GUI - eg: the mitigations=off on mine). You'll need to reboot for the changes to take effect after applying them

11:37 2/23 something happened with your network adapter. Diagnostics would also help, but you're going to need to reboot and if it's an add-on NIC card, reseat it in the slot

The screenshot shows your settings for plugins. Whats the Docker settings on that same page?

At the time, you weren't able to connect to GitHub for the primary source of the application feed, so CA automatically switch to its backup feed to carry on. Try it again in a bit or alternatively give your server static DNS addresses (208.67.222.222 and 208.67.220.220)

Just include the exact same page file preclear is to create that section

Contact support and include q copy and paste (no screenshots) of what shows up within Tools -Registration

You've got emhttp running twice in the go file. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & /usr/local/sbin/emhttp & . . . Does it work if you remove one of those lines?

As previously mentioned, Not True. Simply no more updates for CA running on 6.11 FWIW, Pretty much any version of CA which is currently running on the applicable OS version of Unraid (including going back to CA running on Unraid 6.0) does still work no problems. And, FWIW my decision to drop 6.11 support came before I knew about the licensing changes. It wouldn't have really mattered either way on dropping support though.

Oh, and FWIW veto files slows everything down.

From Finder, you have to first navigate to the TM share in order for TM to see it. IE: The Mac has to have it mounted first. After adding it in, TM will automatically mount it. NOTE: I don't recommend having TM shares moving to/from the array or cache. IF something happens in the middle of the move and everything doesn't get moved for one reason or another, the backups get trashed. Leave it on the cache pool or write directly to the array. Also, TM shares moving from cache to array (and vice versa) has not been fully tested under all circumstances to begin with.

Highly unlikely its CA. But if it ever happens again, delete /config/plugins/community.applications/community.applications.cfg from the flash drive and then try another page without rebooting or deleting anything else will tell you if it was CA itself

Sure. No argument per se on that one. But, the point of this patch was to remove the support requests from how the docker executable handled things since 2015 vs today, and based upon at least one person who surprised me by getting caught by it is likely a widespread configuration mistake. And the effects of what docker changed also happens on an update resulting in an orphaned container. Or to put it another way, the point of the patch isn't to make the user's life easier, but rather everyone else who has to continually answer the posts about this that will go on and on and on. The user's life being easier is simply a nice side effect... Did 6.12.6 not fail when the template referenced a non-existent device (eg: /dev/dri15?)

All future releases of the OS have the same code patch included