Squid

That's not the diagnostics, but it appears that [8086:15bc] 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10) is in the same IOMMU group which means that you won't be able to passthrough the audio device in the same group. As before, you can try ACS override to see if it makes a difference in the applicable groupings

Top of my head, (but take with a grain of salt since I don't use Plex), but maybe you'll have to give Plex a static IP address in the template instead of having it set to HOST so that it winds up on the same network as everything else instead of on the default docker network.

There's other devices in IOMMU group #9 (diagnostics would show us which ones)

I know that when I re setup my sonarr / radarr (in conjunction with NZBGet), one of them failed the test if I didn't include the category Doesn't cost anything to try (and only helps with the organization in the completed downloads folder)

I think the defect is instead that the START button is enabled if nothing is checked off against what to run the tool against. It does work if you select something to run it against.

All docker safe new perms is is a wrapper for the stock new perms script (tools - new perms) that runs it against every share except for your appdata share The script itself is function process { list="$1" [[ $# -ge 2 ]] && owner=$2 || owner=nobody [[ $# -ge 3 ]] && group=$3 || group=users ifs=$IFS; IFS='|' for dir in $list; do echo "$dir" if [[ -d $dir ]]; then echo processing "$dir" echo ... chmod -R u-x,go-rwx,go+u,ugo+X "$dir" chmod -R u-x,go-rwx,go+u,ugo+X "$dir" echo ... chown -R $owner:$group "$dir" chown -R $owner:$group "$dir" echo ... sync sync fi done IFS=$ifs }

Hmm...

What is the contents of /config/domain.cfg on the flash drive?

And if it's never been enabled, then libvirt.img doesn't exist, so no backup will happen of the file

The next obvious is that VMs aren't enabled.

Have you tried creating a category in Sab and then giving it that in Sonarr?

Just issued an update where from the command prompt mover stop will passthru to the actual mover script

That output makes zero sense, as even with the plugin installed, a mover script is still available. This plugin is a wrapper for the existing mover script. No modifications get made to the existing script, so manual controls are a hair different. Your pkill command kills the wrapper, but doesn't kill the original mover that's running. Hence why you have to wait a couple of hours. What you want to do is mover.old stop

I wouldn't expect it since subsonic is closed source. Switch to libresonic

Typo on my part when doing maintenance on CA. All fixed up now.

Docker / Dashboard page, click on the app and click Terminal. Note though that any changes you make inside a container will be lost on any updates to the image.

For what purpose?

Flash drive?

This behaviour has existed forever also.

Parity is always maintained on any write to the array.

Here's one for sure https://forums.unraid.net/topic/72568-user-share-homes/ I'll try and research in the next few days. But like I said, there are also characters valid in share names that are invalid in FAT32 that wind up having emhttp spam the logs. Nov 14 00:57:10 Tower emhttpd: error: put_config_idx, 609: Invalid argument (22): fopen: /boot/config/shares/:.cfg https://forums.unraid.net/topic/75534-cant-pull-from-depositry/?tab=comments#comment-696730

https://forums.unraid.net/topic/57181-real-docker-faq/?page=2#comment-566086

Sounds complicated and confusing. Since we're still tied to FAT32 for config storage, all the important thing I wanted to have happen was that if a share had a forbidden character in the share name that some sort of algorithm takes place to prevent emhttp from spamming the syslog with errors (because the share name is still perfectly valid under linux) (Which your post does not address) The movies vs Movies vs MOVIES and SMB exporting and the complication of NFS and your idea I think will confuse the hell out of everyone when it does happen. Perhaps an entry in the diagnostics in the shares section stating when a naming collision happens would be in order. Another side note is that there are also reserved SMB names that are also perfectly valid share names that cause problems. EG: "Homes" as a share cannot be properly exported and should have a warning issued if creating the share via the UI.

Just having some fun here, but don't they know what the permissions are supposed to be?