wgstarks

Attach the contents of supervisord.log (in your appdata folder) to your next post. Be sure to redact users and passwords.

Has the current version of the NUT docker been updated for compatibility with the RC builds for unRAID?

I believe it will unpack any file it detects in the download location. Haven’t tested this though.

I use the Unpackerr docker for this.

You can scroll through the screenshots on the frigate webUI.

Last time there was some change to the Plex data while the backup was in progress. This time that didn’t happen.

Worked.👍

What about other apps/dockers?

Just click the status tab.

Alright. Will wait for the fix then.

I’ll check this evening but IIRC you are right. Will try enabling increments if it isn’t already and report the outcome.

Same thing again this morning so the problem seems to be repeatable.

Last night my parity check paused during an appdata backup (as configured) but never resumed. After about 16 hours I went ahead and resumed the parity check manually. brunnhilde-diagnostics-20230417-1858.zip

I haven’t tested this but if you copy the appdata folder to the new location preserving all attributes and change your docker’s appdata config to point to the new plex folder it should work. Test before you delete the old Plex appdata folder though. And you should be aware that if the SSD is connected via a USB 3 port that can sometimes be a problem (although hasn’t been for me).

Attach the contents of supervisord.log to your next post. Be sure to redact users/passwords.

Instructions for creating a VLAN in pfsense are here. You’ll need to configure the switch so that traffic with that tag is allowed to the unRAID and cameras. Also need to setup a docker network on unRAID using that VLAN. IMO, you should probably also create rules on the pfsense to block the VLAN from WAN.

I created a VLAN in pfsense and configured my ethernet switch to allow both LAN and VLAN traffic to the unRAID server with port tagging. You’ll have to have a switch that supports this.

The problem is that many people have dockers running that they don’t want to stop for the time needed to preform the backup. This often results in a failed verification because the backup doesn’t match the original data since it changed during the process. The test doesn’t know what changed. Only that the two data sets don’t match. If the verification fails then the backup isn’t saved. End result is no backup. Personally, I stop my dockers before running the backup and never have any issues. For people who don’t want to do this they can at least get a backup by disabling verification even if there is a chance that the backup may not be valid.

A brand new install of what? If it’s the latest stable branch (6.11.5) then it does work for most people and you should post more info to get to the bottom of your issue. If it’s the newly released RC (6.12.0-RC1) then you can expect that by the time 6.12 reaches stable any issues will be corrected.

Thanks. I actually had that prior to this implementation by just adding my self-signed certificate to the keychain on the machine(s) I use to access the server. I can’t do any testing right now since I just finished disassembling my entire network as part of a move but will see how it’s working once it’s all setup again.

Or perhaps you’re referring to compatibility with the latest RC?

Mine is working just fine. I suspect this is a problem local to you.

Out again. I'm not sure what I gain from using myunraid.net? Seems to have a lot of issues and very little support. I think it's time to delete it and that'll be one less headache.

I think maybe you mean 6.12.0 RC-1. You should post issues here.

Looks like this issue has finally resolved itself. Not because of anything I did though. Guessing LT is still making changes behind the scenes. Or maybe it really was an issue with let’s encrypt.