BurntOC

That's what I figured as I worked my slow mind through it, but I'm glad I asked to be sure. Thanks for the response, and for the great plugin.

Greetings, all. I have a Home Assistant VM running and I've been passing my Z-wave and Zigbee dongles to it successfully for a long time. Now Zigbee2MQTT is getting twitchy, which appears to be an open issue with the newer versions and my hardware, but I am trying to minimize any hiccups. As passing both dongles seem to work whether or not I map them both as ports, both as devices, or one of each (even though they both show as CP210N UART Bridges in the USB Manager mapping, my question is this: Is one of those configurations preferable over the others? Even when I pass as port I set the devices /dev/serial/by-id in Home Assistant, so it doesn't seem to matter but I just wanted to double-check.

Fixed it myself. In case this helps others, here's my template, through you'd want to verify the network type and paths match what you want. <?xml version="1.0"?> <Container version="2"> <Name>NextPVR</Name> <Repository>nextpvr/nextpvr_amd64:stable</Repository> <Registry>https://hub.docker.com/r/nextpvr/nextpvr_amd64</Registry> <Network/> <MyIP/> <Shell>bash</Shell> <Privileged>false</Privileged> <Support/> <Project/> <Overview>NextPVR TV recording and video player software.</Overview> <Category>MediaApp:Video</Category> <WebUI>http://[IP]:[PORT:8866]/index.html</WebUI> <TemplateURL/> <Icon>https://hub.docker.com/r/nextpvr/nextpvr_amd64</Icon> <ExtraParams>--security-opt=no-new-privileges</ExtraParams> <PostArgs/> <CPUset/> <DateInstalled>1695046806</DateInstalled> <DonateText/> <DonateLink/> <Requires/> <Config Name="Recordings" Target="/recordings" Default="" Mode="rw" Description="Recordings Folder" Type="Path" Display="always" Required="false" Mask="false">/mnt/user/media/recordings</Config> <Config Name="Buffer" Target="/buffer" Default="" Mode="rw" Description="Live TV Folder" Type="Path" Display="always" Required="false" Mask="false">/mnt/user/appdata/nextpvr/buffer</Config> <Config Name="Configuration" Target="/config" Default="" Mode="rw" Description="Configuration Path" Type="Path" Display="always" Required="false" Mask="false">/mnt/user/appdata/nextpvr/config/</Config> </Container>

Got it working, thanks.

Based on older comments here, and much more recent ones in the NextPVR forum, it looks like some folks have had success with this, but I can't find an actual working template from the last 2 years. Anyone willing to share one?

Alrighty then, LOL

Hi all, revisiting this after some successful tests a couple years back. I'm ready to migrate from Unifi and I've gotten one of my two new switches adopted, though I did enable cloud access to do that. I'd strongly prefer NOT to enable cloud access, so now that I've disabled it I cannot for the life of me get the controller to show the second switch I want to adopt. The controller and the switches are on different subnets and VLANs, but I believe the port for the container (Unraid GUEST interface VLAN/net) and the switch (INFRA VLAN/net) have the PVID and tagged VLANs set properly, and I can ping back and forth both ways. I also have all the 29810-29816 ranges,18043, 27001 (and actually just all the dang high ports for now) opened between the two on the firewall. Lastly, I've gone into the new switch interface and told it the IP of the controller. All that done and I just cannot get it to show. I figure many of you are running standalone with cloud access disabled. Any advice on how I can resolve this?

Seems like deleting my docker image fixed it.

Did y'all ever fix this? The ongoing instability issues I have had with 6.12.x on my 11th gen i5 drove me to downgrade back to 11.5, but none of my containers will start. They are giving the same messages you were seeing.

Same here.

Okay, thanks. I mounted in maintenance mode and did a file system check without the -n flag on those drives and the error hasn't shown back up yet. I'll give it a bit more time and them mark this as solved if it doesn't happen again.

I noticed a FCP error today that said my /var/log was getting full. In looking at it, the culprit seems to be that the logs are getting spammed by these 3 messages over and over. Aug 9 07:41:58 myunraidserver kernel: XFS (dm-0): Internal error !xfs_dir2_namecheck(dep->name, dep->namelen) at line 466 of file fs/xfs/xfs_dir2_readdir.c. Caller xfs_dir2_leaf_getdents+0x220/0x322 [xfs] Aug 9 07:41:58 myunraidserver kernel: CPU: 10 PID: 1579 Comm: find Tainted: P BU W O 6.1.38-Unraid #2 Aug 9 07:41:58 myunraidserver kernel: Call Trace: Any idea what might cause this, and how I can fix it? My array is xfs, as you can see from the message, and I have a single parity. Also a cache drive that's xfs, fwiw. Also, the 6.1.38 reference looks interesting to me. I'm not sure what that's referencing, but I'm on version 6.12.3.

So weird....I'm on vacation and thought I'd pop it to check for an update and it seems I somehow didn't post the reply I'd typed out somewhere. Anyway, I'm not routing any containers through another container. I have a quad NIC with each port having one or two VLANs and each of those with their on /24 subnet. The *arrs and this container are on the same VLAN and each has a static IP assigned in the same subnet. It is working for over 20 other containers, but I can't get them to be able to connect to this one for some reason.

What is the secret to getting other containers (like Sonarr) to be able to connect to this?? I had hotio's version running, then decided to switch to OpenVPN to avoid some logging issues. Each of my *arrs and this container are on the same /24 subnet and I even just used the same IP and login credentials as the hotio container. No dice, they won't connect. They can ping this container, but not access it. I'm using the default ports (except for the peer of course) and I've tried putting 8080 in vpn input ports, output ports, both, neither, and it fails every time.

Sorry for the delay - I'm not getting notifications on this. Been a crazy month so my memory is shot, honestly, but IIRC I just restored via my appdata backups.

I've tried downgrading the MariaDB release to several of the prior versions. It shows successful on install, but they all fail with this same error.

So 6.12.x was giving me fits. I downgraded back to 6.11.5, but I also had to use mover and dynamix file manager to move my files off cache and reformat back to xfs, then put the files back on (since 6.11 didn't natively support zfs). My other containers are starting fine, but I have 3 Mariadb dockers that are throwing errors like this: Caught SIGTERM signal! UMASK corrected from 022 to 0640 ... 230628 16:41:31 mysqld_safe Logging to '/config/databases/c6cc2824f233.err'. 230628 16:41:31 mysqld_safe Starting mariadbd daemon with databases from /config/databases I tried changing the UMASK to 0640 in the template but it seems to revert. I tried copying the directory from an extracted backup and it fails with a different error. Thought maybe permissions needed to be reset to nobody:users and 744 like the others, but the error remains the same: ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── Setting Up Initial Databases Couldn't set an owner to '/auth_pam_tool_dir/auth_pam_tool'. It must be root, the PAM authentication plugin doesn't work otherwise.. Cannot change ownership of the '/auth_pam_tool_dir' directory to the 'abc' user. Check that you have the necessary permissions and try again. Installing MariaDB/MySQL system tables in '/config/databases' ... Installation of system tables failed! Examine the logs in /config/databases for more information. I also have one PostgreSQL database that is erroring with this type of message, but it seems it might be continuing to launch properly after that and chmod and chowning as above didn't seem to help here either. 2023-06-27 22:54:22.998 PDT [30] WARNING: could not open statistics file "pg_stat_tmp/global.stat": Permission denied 2023-06-27 22:54:23.008 PDT [30] LOG: using stale statistics instead of current ones because stats collector is not responding 2023-06-27 22:54:23.008 PDT [30] WARNING: could not open statistics file "pg_stat_tmp/global.stat": Permission denied 2023-06-27 22:54:40.470 PDT [243] FATAL: could not open file "global/pg_filenode.map": Permission denied 2023-06-27 22:55:10.539 PDT [1] LOG: received fast shutdown request 2023-06-27 22:55:10.539 PDT [1] LOG: could not open file "postmaster.pid": Permission denied 2023-06-27 22:55:10.540 PDT [1] LOG: aborting any active transactions 2023-06-27 22:55:10.541 PDT [1] LOG: background worker "logical replication launcher" (PID 32) exited with exit code 1 2023-06-27 22:55:10.541 PDT [27] LOG: shutting down 2023-06-27 22:55:10.542 PDT [27] PANIC: could not open file "/var/lib/postgresql/data/global/pg_control": Permission denied 2023-06-27 22:55:10.542 PDT [1] LOG: checkpointer process (PID 27) was terminated by signal 6: Aborted 2023-06-27 22:55:10.542 PDT [1] LOG: terminating any other active server processes 2023-06-27 22:55:10.542 PDT [31] LOG: could not open temporary statistics file "pg_stat/global.tmp": Permission denied Any ideas why just my databases seem to be jacked and how to fix them? UPDATE - yes, the PostgreSQL db seems to be working okay for Immich. This just seems to be a problem with my MariaDB containers.

Thanks for the response. In reading that on the Downgrade instruction page it had confused me. I presumed I misread it as I didn't recognize them as compressed files without an extension. I ended up copying the config files from my backup last week, reformatting cache to xfs, and using previous apps to reinstall all of my containers. Other than the fact that most didn't originally start and showed "not available" despite having installed the Docker Update Patch plugin, they seem to come up after a forced update. I'm going to reboot when done with that, but I'm optimistic that I'm back on 6.11.5 ok. Marking as solved for now. UPDATE - Welp, that's depressing. Seeing all sorts of oddness now. Can't SSH in on some of the interfaces I could before. None of my containers autostarted as configured. They can be manually started, but I can't access any of them. Guess I'll have to start back with the bz file extract and restore again. UPDATE 2 - I ended up wiping my Unraid usb, copying all the files from the backup archive I made several days ago, and then copying the bz* files from the 6.11.5 as @JorgeB suggested and it seems to be working again.

So the 6.12.x firmwares have caused serious instability and performance issues with one of my two servers. I finally decided I'd had enough and this morning I ran mover, reformatted my cache drive from zfs back to xfs, and I attempted to downgrade my firmware to 6.11.5 My understanding was that you download the zip file, extract it, and copy those files and folders over the ones on your usb. I did that, and when I booted I realized I had a default config when I saw the server name "Tower" and it wouldn't accept my credentials. It's been probably a week since I did a server flash drive backup, in a moment of laziness this morning instead of doing that I did at least copy my existing config directory off in case I needed it. Anyway, I copied that config directory over the one on the usb and tried to boot, but now I'm not even seeing a gui. Can someone tell me how I fix this?

I figured out that removing macvlan via modprobe and clearing out the syslog entries for it stopped the bogus message (credit to another post here for that). I'll probably do the diag submission, but honestly I'm tempted to wait a month or two to see if kernel updates fix it as there seems to be a number of these oddities with 11th gen systems right now.

The server hangs finally drove me to abandon macvlan for now and I flipped the switch back to ipvlan again. I've rebooted a couple of times since for various reasons, then in reviewing my FCP scan this morning it is still reporting DOZENS of macvlan call trace warnings - and I'm not running macvlan. Meanwhile my very similar Unraid server with the same model quad nic and pretty similar network setup (on a 10th gen Intel vs the 11th gen on this one) hums along on macvlan very nicely. Frustration peaking.

As I mentioned in my previous post, I have a quad port Intel NIC and each port has it's own /24. Each goes via a managed switch to the firewall where again, each has a specific VLAN assigned (so not in Unraid interface settings). MOST all my containers have an IP assigned, and host access is disabled in Docker settings. NO containers are assigned to br0. While I ran pre 6.11 with no issues, unfortunately I swapped the NIC and drives from an AMD 5900X/X570 build to an 11th gen Intel and mobo combo around the time 6.11 was out and at some point FCP started reporting macvlan call trace warnings and I also started having these server hangs. By my understanding, I've follow all the steps, but I continue to have this problem unless I switch to ipvlan. Frustrating.

@boniel Hate asking dumb questions, but I have to in this case. Does a multi-port NIC count as separate adapters for this solution? I'd assume so, but I've moved all my containers off the br0 interface (on an Intel quad-port NIC port0) and I'm still seeing reports of macvlan call traces. I prefer macvlan to ipvlan because some of my containers require it, and it seems like it would potentially offer better security as all 4 NIC ports are separated by subnet and VLANs into my managed switch and then into similarly separate NIC ports on my firewall. Just trying to figure out how to get rid of these call trace errors and improve stability.

Okay. I checked the filesystem so I'll look at safe mode testing.