anibis2

I no longer see this issue when rsyncing to a remote smb share on 6.12.10-rc.1.

It looks like Freefilesync adds /mnt/user as the source storage by default; this won't pick up the remote shares. You'll have to change that to just /mnt, then you'll be able to access /mnt/remotes from Freefilesync. Using /mnt/user will only give your Unraid shares.

You can transfer to a share using rsync/Freefilesync, you just have to mount the share to Unraid first. Kinda like a mapped drive in Windows. You can use the Unassigned Devices plugin to take care of the mounting, then rsync or use Freefilesync for the transfer.

I downgraded directly to .8.

I am also seeing this error when I rsync my data to my backup machine. Downgraded without issue.

I have no option to create a snapshot when clicking on the "Actions" menu on a particular pool. I have a second ZFS pool that I use for VM's, it has the Snapshot option. My cache pool does not have this option, it simply has "Move/Rename". Any ideas? *EDIT: I figured it out, I had shares and not datasets. Not sure why that happened in the first place, but it's fixed.

It ended up being a misconfiguration on the VPN that particular host uses which was blocking LAN access. I did clean up my users, so thanks for that info.

Ok, so I removed the plugin and updated it to your 2.8.0 release, this has gotten rid of the Access Denied error. I believe I misinterpreted the error; it was actually triggering when I would start/restart the service. I see no errors when I try to connect the client to the server, WinNUT just hangs for about 30 seconds then says it cannot connect. Here's my config, the log is attached: MODE=netserver [qnapups] driver = usbhid-ups port = auto LISTEN 0.0.0.0 [admin] password=***** actions=set actions=fsd instcmds=all [root] password=***** upsmon master [admin] password=**** upsmon slave MONITOR [email protected] 1 root ***** master SHUTDOWNCMD "/sbin/poweroff" POWERDOWNFLAG /etc/nut/killpower NOTIFYFLAG ONBATT SYSLOG+EXEC NOTIFYFLAG ONLINE SYSLOG+EXEC NOTIFYCMD "/usr/sbin/nut-notify" NOTIFYFLAG REPLBATT SYSLOG+EXEC NUT.txt

I updated to 6.12.4 yesterday and am having issues with my remote NUT devices. Unraid itself sees the UPS just fine.

When is the docker going to be updated with 27.0.2? It's been a few days now...

When I try to exclude my Grafana data directory it slows down to a crawl. The .tar was growing slowly as time went on, and there was I/O activity on the disks. The Grafana tar was 500MB after 20 minutes of running Plex, which is 32GB and has many more files, takes about 90 seconds. I just turned off the external part on Grafana and it's working well now, takes about a minute. *EDIT* I wasn't paying attention with Grafana, I didn't realize how the docker path mappings were configured. I was excluding my DB's, but there were other container paths pointing to the root Unraid file system. I didn't catch that even though you pointed it out, but now I get it. The plugin is working fine for me nothing out of the ordinary.

That's definitely much better. Exclusions appear to be working as expected, as is the "Save external volumes" setting. The coloring is better as well. I had a different issue when it tried to backup Grafana. The debug log is attached. Not sure if it's app related, or something with my configuration. ab.debug.log

Ah, maybe it was just backup to an external drive. Regardless, the setting is set to no. Kinda hard to read with the coloring issues.

I do not see a setting for "Backup external volumes". I do remember seeing it on the old Appdata Backup plugin. I did try disabling the flash drive / VM meta backup, but there was no change.

I'm having the same issue with Plex. The .tar for my 32GB Plex appdata folder was up to ~250GB before I stopped the backup. I tried excluding my media folders thinking it was grabbing those, but that didn't affect anything. I also tried to exclude my Grafana db's, but nah. Good thing we're in beta. Also, I run Unraid in dark mode, and the coloring is off when you drive to the individual docker settings.

I had permission issues with the docker initially, couldn't write to config or apps. I think it was from the Unraid permission tool; I had to run it on my cache drive a couple months back. 26 seems fine to me. My instance is pretty small though.

It's fixed for me with the new docker image. I'm on Nextcloud 26 and am not seeing any issues other than an X-Robot-Tag error in Nextcloud admin, but I have verified that my X-Robot-Tag set.

Here's a one-liner from the above thread that fixes the docker update issue. It does the same thing as manually editing the file. Just ssh to your box / use the Web terminal and paste the command. sed -i "s#distribution.manifest.v2+json'#distribution.manifest.v2+json,application/vnd.oci.image.index.v1+json'#" /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php This will not persist when you reboot Unraid. The real fix will be in the in the next Unraid release.

They both work. The one I linked is the most recent release that I could find where hardware transcoding still worked. I didn't see the need to go all the way back to 1.24 as I only encountered this issue recently.

Ah nice, just making sure. I was making some changes to my firewall when I noticed it was bombing, wasn't sure if I broke something on my end or what. I see the package was updated yesterday, so probably something from that.

Is anyone else having problems updating the app since yesterday? Both Tdarr and Tdarr Node.

For those people having hardware transcoding issues, I switched to the last major version which resolved the issue for me. Just change the repo from linuxserver/plex to linuxserver/plex:version-1.29.2.6364-6d72b0cf6 Once a fixed version of 1.30 comes out just switch it back to linuxserver/plex

I am having the same issue, fully updated all around. It stopped working within the past couple weeks, but I'm not sure exactly when. I also tried the linuxserver/plex repo and had the same issue. I can see the transcode start, but the stream doesn't start. *EDIT Seems to be a known bug: https://forums.plex.tv/t/quicksync-hardware-transcoding-error-4294967279/829247/6

Correct, you can re-enable bridging and everything should work as it usually does.

Go into Settings > Network Settings > Routing Table, then add a route pointing your local subnet (192.168.0.0/24 in my case) to br0. It should look like that when you're done. There will be other routes for your docker subnets, as well as ipv6 if applicable. Just leave those alone.