aglyons

If I go by the understanding that enabling the custom network to allow for the bridge to work, and instead of enabling the eth0 custom network, I assign a static IP to the eth0.2 VLAN custom network, that should be the bridge network accessible from x.x.202.x:[port] But that doesn't happen. What has happened is that my Unraid UI is now accessible from both x.x.200.x and x.x.202.x, and still no containers on the default bridge are accessible. (^^ I noticed and corrected that eth0.2 was added to the listening devices list. It is again only accessible from 200.x) All this time, the containers on x.x.202.x and all containers on HOST (x.x.200.x) have been fully accessible. I should add that this is only on the default bridge. I have some compose containers that create their own bridge networks, and both of those work fine. Question to the devs (or those that know): Has the bridge kernel panic issue been resolved fully, or are we still relying on the workaround described in v6.14 release notes?

So if I had enabled the custom network on eth0 in the Docker settings, the Unraid UI becomes unavailable. The thing is, I WAS able to access all containers on the bridge up until recently. I'm not sure what changed. I'm sure it wasn't anything I've changed, as I haven't changed anything regarding the network config for about a year now. Currently, with eth0.2 enabled, the Unradi UI is available on the 200.x network and all my Dockers on eth0.2 (202.x) are accessible, as are all containers running in Host mode (200.x). It's only containers on the default bridge that are not accessible to incoming traffic. Outgoing traffic works fine AFAIK. So, as stated, the Unraid UI is accessible with custom network eth0 disabled. I just had a thought that when the system starts up and Docker has not started, it is still listening on eth0. If Docker is not set to start, the Unraid UI is fully accessible. When Docker kicks in, I suspect that eth0 interface gets replaced by br0 but the Unraid system remains set to respond to requests only on eth0, not br0. That switch does not get changed in the Unraid Networking listening interfaces config.

I have a few containers that are local access only, so I put them on the bridge rather than my custom VLAN. I can't be 100% positive, but at some point, none of the containers on the bridge are accessible. They can ping the internet, but I can't bring up any UI pages using the IP:port assigned. I went through my network settings following the config described in the 6.14 release notes (I use MACVLAN for my cutom networks), and on the Docker page, if I enabled the custom network for eth0 as described, I would lose access to the Unraid WebUI once Docker got started. I've restored the config I had so I can get back into the server, but all of the bridge mode containers are still down. knoxx-diagnostics-20250402-1427.zip

I think people are confused as to what I am taking about and what I think others have tried to point out. As it is now, each plugin/template has a single thread where everyone replies with every issue. It's a massive headache to find anything and then track the relevant conversation amongst all the other chatter. What I am suggesting is instead of the plug-in/template being a thread, make that a subforum so that separate posts can be made inside. Each post then has it's own topic and it's easier to find things and keep things on topic. This is not creating thousands of subforums.

True, most questions are about the app, not the template. But being a public forum, it's not just about the author answering questions about their template. A lot of the community jumps in and helps out. I jsut posted in the Docker Compose plugin thread and as always, I try to go though the posts that were already there to see if my issue had already been discussed. But there are over 40 pages of posts with conversations all merged together in one big mess. In order to find if anyone had already run into the issue and solved it one would have to go through each page, read the start of each post and then try to piece together the thread, which gets broken up with other posts about other things. I don't see why having subforums for each author, which in turn has multiple subforums for each item they manage, is such a problem. I've seen public forums that are way bigger than what was proffered as a reason to not go there. Impossible to enforce is also not true. Limetech sets the rules by which plugins are authored and are accepted into the CA. Why should this be any different? Just because something has always been done a certain way doesn't mean it is the right way or should continue.

typo in the post. It is and always was a jpg file. It's saved as a jpg and entered in the icon field as a jpg. The problem remains. EDIT: The icons HAVE to be png? Why is that? The icons were showing up correctly in the appdata backup plugin list, just not the UR docker containers list.

Feature Request I just found out that we can add the Compose tab to the main UR menu bar. I thought it odd that while it shows the compose file entries, it doesn't show any compose containers. I would like to be able to keep only template containers on the Dockers tab and have the compose containers listed on the Compose tab. While they are all Docker containers, having the option to keep them separated would be nice to keep things organized.

I have had this thought for some time now and was just about to write something along those lines. If you're a plugin or container developer contributing to the community, I think it would be fitting for the developer to be provided with a subforum where they can create a sub-subforum for each plugin/container they author and manage. This would keep all posts in the respecting forums on point. As it stands, an author could have more than one item they manage and trying to follow one specific item amongst a single massive stream of back-and-forth conversations is confusing and exhausting. I have found myself, on many occasions, skipping using the UR forum entirely and searching through Google instead. More often than not, I find answers or solutions NOT on the UR forums but elsewhere, mainly due to the sheer number of unrelated posts and noise one has to weed through here. Regarding the '2688 forum sections' being 'impractical.' That is called organization. Each author looks after their own forum's content. Organized this way, nobody would need to go through all 2688 posts to find what they are specifically looking for, but as it stands, people DO need to weed through 100-200 non-relevant posts to find just the next step when trying to fix their problems. Organizing makes things easier to find, not harder. +1 for cleaning up the forum structure

Container icons not showing due to HTML coding issue There appears to be some coding issue somewhere, either in the Compose plugin or Unraid itself when it comes to showing icons defined in the compose plugin UI. I have the icon, in jpg, stored in the appdata folder of the container, and I have set all the defined containers in the compose file set to use the same icon file. No icons show in the UR docker container list. but digging in the code shows that it's trying to. The green highlighted span above shows the corrected code based on the working icons in the UR docker container list. The red highlighted span shows the code generated by either UR or the compose plugin. For some reason, it treats the <img> tag as a <i> tag (used for displaying fonts in italics) and applies a 'fa' class along with trying to apply another class using the icon file path and filename as the descriptor. This problem is not a cache issue but a programmatic problem with how Compose passes the icon data to UR for rendering or how UR processes the data it is passed. PS. On another note, some people put icons on the boot thumb drive, but I would avoid doing so as it adds more content to the thumb drive, requiring further activity on the disk.

I see 7.0.1 is out. Alas the kernel is still below 6.7. Still patiently waiting for a kernel update so I can get the APU working. But the wait is getting painful!

Is there a way of creating multiple arrays? Here are my thoughts on why I would consider going there. I recently came across a Reddit post about a sysadmin who had a dual drive failure on an array he built. Luckily, it wasn't in production at the time, but it reminded me of a thought I had about arrays and parity disks. Currently, Unraid provides up to two parity drives. This should be sufficient for most people in most situations. But, as the number of data disks in the array increases, the probability of a multi-disk event also increases. A six-disk array with two parity drives will have a lower likelihood of a multi-disk event than a 24-disk array with two parity drives. The ability to create multiple arrays with a smaller number of data drives and parity drives would keep this probability factor down while still providing the overall storage capacity. The shares could still be spread across all of the arrays. Thoughts?

I wouldn't worry about it. More wear happens when powering up rather than when keeping it spinning. Besides, I don't think it will take years to resolve this issue.

With the release of UR7, the kernel in this release is still below the version that has kernel support for the Ryzen 5 8500G APU. Is there any way to get this working in UR7 in a similar way that Nvidia drivers are installed? Does the kernel HAVE to have the device support in it before installing drivers would even function?

Something that didn't come up a an error is the mover tuning plugin. With that installed the mover wouldn't move any files. There was an error message (which I can't recall), I did find a post in here somewhere that concluded it was the tuner plugin causing the problem. Once I uninstalled it the mover started working again.

Next question (could ya see that coming lol) OpenZFS is supported in 6.12 How long till work on 7.1 is started and how far out has a .1 release normally taken?

Thanks for everyone's hard work on bringing V7 out!! Question: How often with new releases is the kernel updated? I was hoping to see at least kernel 6.7 in UR7 but we didn't quite get there on this release. My Ryzen 8500G still can't use the APU to do my Plex transcoding, so I am stuck using the Nvidia 1050ti, which runs in a PCIE slot with only one lane. The Ryzen 5 series with the 740 APU is supported under Kernel 6.7 going forward.

I've noticed a discrepancy in capacity stats between Unraid and ZFS Master. One of my cache pools (2 drive mirrored ZFS) is reporting 483GB capacity. ZFS Master is reporting 464GB. The Capacity used is also reported differently as 409GB in UR and 381GB in ZFS Master. Exploring the dataset from ZFS Master and calculating the capacity used reports 409GB I'm not sure who would own the issue, whether that's UR or the ZFS Master.

Thanks for the vote! The problem with your solution is the order you have them determines the startup order when the array starts up. If you have containers that are dependent on another container, it could cause issues if the dependence isn't started first.

I may be in the minority, but I assign IPs to each container on a dedicated Docker VLAN. The challenge the Unraid UI poses is that it doesn't present the allocation table in an organized way. Over a year ago, I posted a feature request to group/sort the containers by network and list them in numerical order by IP address or allow for sorting by IP or ports. That hasn't happened yet, so things are still currently sorted alphabetically by container name. Has anyone found or made a plugin/addon/script that can query the system for all of the allocations and list them out neatly?

So we'll get there eventually. It's just a little bummer that I'll have to wait a little longer before I can use the iGPU in the 8500G. I'm stuck with the 1050ti, which is stuck in a PCIE16 slot running on 1 lane, so transcodes are crawling at CPU speeds!

I see ZFS 2.3.0-rc3 has been aligned for Linux v6.12.1. Just waiting for one commit test to complete for freebsd13-4r. Fingers crossed that ZFS 2.3.0 is released in time for URv7 to jump up to Linux 6.12.x which has been marked as LTS.

Please forgive if there is a more appropriate forum for this question/discussion. Feel free to move it there if applicable. Disclosure: I'm not a Linux guru by any means so my lack of accuracy may be a contributor. I recently moved my UR server to newer hardware in a new chassis consolidating another server running some Docker containers (Plex, Tdarr) on bare metal. I went with an AMD R5 8500G on an m-atx B650 board and a new SAS controller. Everything went fine with the transfer. All the drives were mounted and the array is working fine. However, the APU in the AMD CPU cannot be used in the current UR V6.12.14 because of the kernel version 6.1.118. I've done some searching around and from what I can see, these CPUs were first supported under kernel v6.7 albeit using open-source drivers. It was not supported until v6.11rc2 with the latest stable kernel version being v6.12 that addressed random reboots when using virtualization -a significant issue with use in an UR scenario. Which brings us to UR v7 rc1. I see in the release notes that UR7 is based on the kernel v6.6.62. That would lead me to understand that these CPUs are still not going to work properly with the latest version of UR until the kernel version gets up to and beyond kernel v6.12. TLDR: Why the choice to use kernel v6.6.62 in UR7 when that version is significantly behind the currently available releases?

So, I've been trying to get this working for a while now and have gotten nowhere! If 'lspro' is a Linux CLI command, it's not working on my system! (UR 6.12.14) I can see the Commander in the hardware list Dynamix System Temps shows none for fans. Dynamix Fan Control also sees nothing. And sensors-detect also finds nothing. I'm not sure what I am missing? Is there a driver plugin I need to install? A kernel config that needs adding to the boot?

I started hunting for info on kernel options -I'd never heard of that before being a Linux newbie. I found the config on the Flash drive, and it looks like mine is the default standard with no other options enabled. The thing is, I'm not sure what I need to put in there to enable the USB_HID. I tried wrapping my head around what was listed on the links you shared, but nothing was clear to me.

Hey @bmartino1! Thanks for pulling that together. I didn't see that post you referred to! I tried the cli commands and oddly enough.....nothing was returned for any of them?! Did I miss something?