aglyons

I've looked around and have seen others writing about creating a VM to control the Corsair Commander Fan hub, but from what I have read about the UR kernel, it should already be there. The Commander Pro was added to Linux Kernel 5.9. https://www.phoronix.com/news/Corsair-Commander-Pro-Linux-5.9 The Slackware v15.0 UR is using is based on Linux kernel v5.15.19. http://www.slackware.com/index.php root@KNOXX:/# cat /etc/os-release NAME=Slackware VERSION="15.0" ID=slackware VERSION_ID=15.0 PRETTY_NAME="Slackware 15.0 x86_64 (post 15.0 -current)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:slackware:slackware_linux:15.0" HOME_URL="http://slackware.com/" SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/" BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/" VERSION_CODENAME=current So, while it appears in the hardware list, sensors-detect fails to find anything, and neither Fan Control nor System Temp sees it either.

I'm not surprised that it worked once downgraded. If the UI JS/CSS files are updated in the new release and the browser has the old versions cached, it will cause UI issues. Now, if this display issue happens on a new machine that has NEVER loaded Unraids webUI, that would be suspect of a bug. If you're running Chrome, just open dev tools (F12) and it has cache disabled by default. I think FF needs to be on the Network tab and make sure the 'disable cache' checkbox is ticked.

From what I have seen with this kind of symptom, flushing browser cache is a first step. Apologies if this was already done, it wasn't mentioned by OP.

****Nevermind. I found the cause from another post that described something different but was actually the same behaviour. Mover logging was logging all files it moved, and diags was going through that log file. I went to pull a diagnostics file and noticed in the output window that it was listing files in a cache drive. It was going to take a month of Sundays to go through all 23GB/150,000 files. I stopped the diag process and moved the files from the cache drive to a different share on the array. The cache drive has zero files/folders, and I ran the diagnostics tool again, and it listed the same files on the cache drive! What is going on here?!

I recently moved my Unraid onto new hardware. I had another Ubunutu system running Docker containers for Tdarr and Plex with Unraid holding the media. I had an Nvidia 1050ti in the Tdarr/Plex system, and when I moved Unraid, I moved the Nvidia card to it. I then added Plex and Tdarr to Unraid and moved the previous Tdarr configuration over, so they are all the same settings. I am seeing a massive hit to performance with Tdarr in Unraid. I easily hit 170FPS processing 1080p 10bit H265 files on the Ubuntu system, which was on much older hardware. In Unraid, I barely hit 60 fps while doing the same thing. 4K transcodes were hitting the upper 80fps, and now, they are 17fps with the same configuration. The GPU activity shows it is barely taxing the GPU encoder/decoder, and the CPU is doing almost nothing. Checking if file access could be the bottleneck, the disks are showing virtually no significant activity either, and the old system was pulling across the network to process video. Any ideas on what is going on here? Diagnostics to come..... ********I think I may have figured out the issue: PCIE lanes! The MB and CPU I've used (R58500G & M-ATX B650) only provide PCIE4 x8 for the first slot and PCIE4 x1 for the other three slots. The first slot, usually for a GPU, I have my SATA controller in it for extra disk bandwidth since it's a 24 port card. That means the Nvidia is in a slot with only 1 PCIE lane. I think the older system had more lanes for the Nvidia card as there wasn't a SATA controller card in it, and that is where I am seeing the performance drop. Now, if only disabling unneeded MB devices (audio, USB ports, etc.) could release those lanes for PCIE slots, that would be awesome. Heck, even the other two PCIE_3 and PCIE_4 slots I could do without if the lanes could be diverted to PCIE_2. But I don't think it works like that. knoxx-diagnostics-20241129-2117.zip

Yes, please help us understand why Unraid seems to be different from every other VM platform. I've run VMware servers and barebones Docker boxes, and I have never seen a situation where an IP is duped with a different MAC. To this day, I still have a duped IP in my Unifi, and I've managed it by flagging it as blocked. Everything works, so it's not as if it is having any impact on functionality. But it does impact things when that MAC is not blocked. I've seen services become flaky and unreliable. It makes sense that packets could be routed to the wrong network port/MAC.

OK, so this is most likely down to the older kernel in URv6x. I'll have to wait till UR7 is released to take advantage of the APU in the AMD 8500G. I had a chat with ich777 about Radeon-Top and he confirmed that installing Radeon-Top is the same thing as un-blacklisting the GPU. Which is not supported yet so that's why everything gets locked up.

Do you have any insight on when UR7 might be going general release? I know we haven't seen any RC releases but then again, I don't know if the UR team do those. If it's not long then I can wait. I'm not a Linux pro by any measure. Simply problems that others solve in minutes can take me days to figure out.

RADEON-TOP UR 6.12.13 Ryzen 5 8500G / Radeon 740M Graphics Forgive me if this was listed somewhere. I've been working on this for quite some time and all the searches I have done have led me nowhere. I've managed to get the system to boot up and the GPU is shown in the device list. I had to blacklist it in modprobe or the whole server would lock up at boot. So now that the system is up and I can see the VGA in the devices, I went to install Radeon-Top. When it came to the last part, enabling amdgpu kernel 'something', the whole thing locked up again. Was this a fluke and I should try installing it again? If the GPU is blacklisted does this pose a problem for Radeon-Top? Is Radeon-Top needed anymore to get the GPU into a Plex container? The GPU Stats plugin can see my Nvidia card and it does see the AMD one but nothing is displayed. Could this be down to the UR kernel not supporting the GPU as yet? (I can't confirm this is a fact but other posts on Linux systems all point to kernels above 6.1.106)

OK, I blacklisted it again, re-enabled it in the BIOS and the server came up with the AMD VGA in the devices list. But now another issue, I went to install radeon-top and when it got to the last part, enabling the amd kernel mode (or something to that extent) the whole system locked up.

I tried that and while it will boot up, the AMDGPU is not accessible to containers.

Is it possible that the CPU is too new for the current kernel in v6.12.113? Could the kernel bump in UR7 fix the issue?

BUMP. Any ideas anyone? I doubt it but could this be a problem if I also have an Nvidia 1050ti installed at the same time? At the moment it's the only way I can get this server started with a functional screen attached. I tried with the iGPU on and set as primary but ended up with a blank screen and no webUI; I assumed the system locked up like it does now but with no screen there's no way of knowing it.

I have been running my UR server on a DellR510 for a few years and decided that I wanted out of the datacenter hardware rat race. I repurposed my docker box and picked up a new MB+CPU, this time an AMD with iGPU so that I can free up a slot on the board. I've managed to get the array all back online but I ran into a problem in that you can't have the iGPU if enabling CSM and NOT booting into UEFI mode -which is how the R510 was booting for ages. I renamed the efi- folder on the thumb drive, disabled CSM and was able to turn on the iGPU in BIOS. The UR boot screen comes up now and it starts the boot up process. I can see where it finds the AMDGPU and starts the driver process. But it crashes with a calltrace and stops dead. after a few seconds the screen scrolls like mad and ends up here; I've searched Google and on here and have not found anything that makes it clear what the issue is or how to fix it. Any ideas?

Hmmm, I'm already underwhelmed by Unraid's array performance. I guess it's tough to have our cake and eat it, too: resiliency vs. performance. I like how files on the array drives are easily accessible in the event of a disaster. However, how FUSE works kills any performance benefit that multiple disks could provide. I wonder if there is a path/plan to replace FUSE with a ZFS-based approach that includes file accessibility on each drive (like FUSE does) with the parity drives the array uses. Or maybe I'm just completely confused about how FUSE works versus ZFS capabilities!

I'm just getting my ducks in a row on a plan. If I convert each disk in the array to ZFS, then I should be able to use those commands to move datasets from the assigned cache pool back to the array. Does this function in any way f'up the FUSE system and corrupt the parity? Do the parity drive(s) need to be in ZFS as well? Currently, the parity drives show no FS at all. My ultimate goal is to reduce the time it takes to move data around in the event of maintenance. I went through this recently, and our entire media system and all my home lab services were down for about 36 hours, just waiting for files to be moved. I'm not really looking for 100% redundancy, but I think that downtime could be cut by 75% just by moving data as block storage rather than at a file level. Hopefully, ZFS can be used in this situation.

Question/Scenario.... If we have app data on a ZFS pool as a dataset, with the inner folders also as individual datasets, if we need to move the files from the pool to the array to do some drive maintenance or relocate things, does the plugin provide the capability to move the datasets as blocks rather than individual files? Would the array drives also need to be formatted as ZFS for that to work? I just went through shifting stuff around and moving 5,000,000 smallish files ended up taking ages. Moving as a block would speed this up massively.

I gave up running VM's on UR and moved my HAOS onto bare metal -a small NUC. I'm still running MACVLAN and I don't have duplicated IP's in Unifi anymore. Network settings have a VLAN created with no IP assigned on the primary NIC. Docker settings are as follows Docker custom network type: macvlan Host access to custom networks: Disabled Preserve user defined networks: No IPv4 custom network on interface eth0: Subnet: 192.168.1.0/24 Gateway: 192.168.200.1 DHCP pool: not set IPv4 custom network on interface eth0.2: Subnet: 192.168.2.0/24 Gateway: 192.168.202.1 DHCP pool: not set Hope this helps sort you out. A.

I honestly don't know what the problem is, specifically with Unraid. I've run VM's on VMware with no issues at all. I dumped VMWare when I set up the Unraid server. When they came out with the "fix" for call trace crashes, they went and did some funky workaround which seems overly complicated and possibly introduces new issues, like this. I'm not sure why UR has such issues with Docker containers using the bridge network. I have another server running Ubuntu with Docker with all containers using the bridge driver and have never had a call trace lockup ever. It got to the point for me that I gave up on VMs in UR and restored the HAOS config onto a small NUC dedicated to HAOS. I'm sorry that I can't give you a solution other than to suggest giving up on UR VMs and possibly considering moving Docker containers to another system running just Docker. One thing that really drives me nuts with UR is HOW docker containers are managed. If no template is created in the apps, it isn't easy to translate a container's requirements into a UR template. I've learned that docker-compose Yaml's are the better way to go, as when you start a container with docker run, when you remove the container, your run command is gone, so you either have to remember all your volume mappings and ENV vars. Compose files are not deleted when the container is in, so all your settings remain. But Docker-Compose in UR is only supported with a plugin. While it allows you to create the Yaml's, there are quirks. Again, there's something weird with defining the network to use. I have some compose containers in UR, and even though I've tried every network named in Docker, it still creates its own network with a useless 28-character name, which messes up the UI.

As I have come to understand, if you are running a container in Unraid that supports GUID/PUID/UMASK, setting them to 99:100, the UMASK should actually be 000. By default, files created by nobody:users in Unraid are provided 777:666 access. UMASK is used to remove permissions from files. It cannot add any. Putting a UMASK other than 000 on a container running with Unraid PUID:GUID would in effect, reduce access to the files created by the container.

BUMP

**Originally posted in MAC/SMB by accident v6.12.13 I have a media share in UR that a remote Ubuntu system, running Tdarr in a container. I have the media drive mapped using an allowed user account in the UR server. Tdarr can access all the files, and it's chugging through everything. But I am seeing that all the files Tdarr pushes over are flagged as created by the user account that was used to mount the share. There's no 'nobody' account in the UR users list. If there's a default password for the nobody account, I am not aware of it. How can I get this remote container to create the files as nobody? Is this even a problem, as I thought it was? Also, I've been wracking my brain trying to find out how to configure the permissions on the Ubuntu server so that it creates files with the correct permissions. By default, the umask on the Ubunutu is 022. I tried setting the Tdarr container to 0000, which wouldn't work as the default in Ubuntu is 0775/0664. I've found several sites that walked through setting the default umask for the system with no success. I've set the Tdarr container to run as 99:100 and tried 0:0, but neither made any difference. All files are created as 0775/0664. While this isn't stopping the files from moving to the UR share, it shows different permissions once moved over.

Let me clear up the confusions. First, I have and always have had the system running in MACVLAN mode. The actual problem is the primary NIC VHOST (vhost0) is being assigned the same IP as the primary NIC. The primary NIC and vhost0 each have unique MAC addresses. As such, the network has two systems with different MAC addr using the same IP addr. The cherry in top being both systems are plugged into the same physical network port! This behavior has only cropped up since implementing the workaround to allow MACVLAN without the call-trace lock ups. What's really confusing to me is if you search online for "Linux, MACVLAN, call trace" all that comes up are UnRaid reports. Even the bug report for the Linux kernel was made by limetech. There are no other reports by anyone else about this behavior. So it seems to me that this is an UNRaid specific issue. I have other Linux systems running Docker with MACVLAN networks that have never had a call trace lock up. So why are we seeing this happen on UNRaid systems?

I don't mean to be confrontational bmartino1, I appreciate your trying to help. But I'm not sure what the concern is with how the VLANs are set up on the UDM. All the services on that VLAN that are served by Unraid work just fine across the network. All of those containers on that VLAN show up as individual clients in the Unifi Network UI, with unique MAC addresses, just as I wanted them to. Also Spanning Tree is for network loops across switches. It would have no bearing in this situation. The settings on the UDM would have nothing to do with the UNRaid server assigning the primary NICs IP to the vhost0 interface. That is what is causing the 'duplicate IP/different MAC addr' problem. This is NOT just shown in the Unifi Controller, it is clear in the CLI output on the UNRaid server itself. NetworkChucks video shows the MACVLan network he created does not have an IP assigned to it at all. So why is UR assigning that IP? Perhaps this is a side effect of the workaround for the MACVLan freeze issue in the linux kernel that came out a little while ago. That is when I started seeing this issue pop up. Once I went through the workaround setup, this behavior started.

OK, so I am not running the controller in a container or VM, I have a UDMProSE. Hardware. IT (unifi hardware is on its own "default" VLAN) Docker (for docker containers or other external services) Family (for regular client devices) Guest (standard unifi guest network) I've watched NetworkChucks video a while back and just watched it again, just in case something jumped out at me. The odd thing is the networks he was creating don't result in the same behavior that UNRaid does. His MACVLANnetwork setup does not attach the same IP as the host. It doesn't assign an IP at all. Here on UR, it does and that is what is causing the problem IMO. To dissect the three points you mentioned; To see unfi lan network traffic you: 1 must have a unifi/ubnt switch. YUP, all my network equipment is Unifi 2 Macvlan docker network driver must be used... YUP, but that's what UNRaid is supposed to be doing in the background, right? 3 have a Mac address that is different from unraids on the docker. Not totally clear what you mean here but the point of the MACVLAN is so that each container on that network will get it's own MAC. So that would mean yes, Unifi should, and does, see each container as a separate client device and tracks the traffic. That is why I want to use MACVLAN. Using IPVLAN, Unifi doesn't see the client and I can't setup traffic rules against them. Bridge is even worse as it all goes though one IP address and one MAC. That also kills anything possible with PiHole (local DNS, etc). So I'm still at a loss here as the way I see it, which is also how it was shown in NetworkChucks video, the vhost should not be getting the same IP as the parent interface. It shouldn't be getting an IP address at all as far as I can tell.