pkoci
Members
-
Joined
-
Last visited
Everything posted by pkoci
-
Hi everyone, I'm running an Intel N100 board with an ASM1166 SATA controller. Apparently after updating to Unraid 7.3, my system stopped reaching C6+ states. Before the update, everything was working fine, but now the power management seems broken and the CPU won't drop into deep idle states. Has anyone else encountered this issue with this hardware combo on 7.3? Have you found any solution or workaround? Thanks for any help!
-
IPv6 macvlan docker network seems broken after upgrading from 7.2.4. Anyone else experiencing this or aware of any breaking changes in the latest version?
-
Do you have any issues with ipv6, docker, macvlan / ipvlan?
-
I have a Mikrotik router and IPv6 works without any problems. I currently use the macvlan driver for the custom network, which also works with IPv6, but containers cannot access the host via IPv6 (even though it is enabled in the settings). The problems described above only occur with ipvlan. What are your Docker settings? Would you mind sharing a screenshot?
-
If I set up a custom network on ipvlan, pinging anything (LAN or even Google, for example) doesn't work. Containers on the ipvlan network get the same ipv6 address as the host via SLAAC. This is probably the problem. And another ipv6 address via DHCPv6. You don't seem to have these problems?
-
What type of the custom network do you use? Ipvlan or macvlan?
-
I meant the host access to custom network. Try to ping from a container to host via ipv6.
-
I dont think that host access works via ipv6
-
What docker network is the plex container assign to? You should use host or macvlan/ipvlan.
-
Hi, After updating from version 7.1.3 to 7.1.4 (and beta 7.2), docker containers running on a custom docker network do not start when the OS boots up. According to the log, the network cannot be found. I did not have this problem with version 7.1.3. The network uses the macvlan driver with host access enabled, bridging is disabled, and the custom network is eth0. I am attaching the logs from version 7.2, but I assume that this is the same problem as in version 7.1.4. Thanks in advance unraid-diagnostics-20250802_0028.zip
-
Hello everyone, I am currently using UNRAID version 7.0.0 beta 2, and I've noticed that my system log is filling up rapidly. The log entries show constant adding and deleting of the route for 2a03:XXXX:XXXX:402::/64, as seen below: Jul 13 17:44:48 UNRAID dhcpcd[1540]: eth0: deleting route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:44:48 UNRAID dhcpcd[1540]: eth0: adding route to fd2b:82ee:67b6:1::/64 via fe80::5802:d6da:8d:3db4 Jul 13 17:44:50 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:44:51 UNRAID dhcpcd[1540]: eth0: deleting route to fd2b:82ee:67b6:1::/64 via fe80::5802:d6da:8d:3db4 Jul 13 17:44:53 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:45:38 UNRAID dhcpcd[1540]: eth0: adding route to fd2b:82ee:67b6:1::/64 via fe80::5802:d6da:8d:3db4 Jul 13 17:45:40 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:46:34 UNRAID dhcpcd[1540]: eth0: adding route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:46:34 UNRAID dhcpcd[1540]: eth0: deleting route to fd2b:82ee:67b6:1::/64 via fe80::5802:d6da:8d:3db4 Jul 13 17:46:36 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:49:09 UNRAID dhcpcd[1540]: eth0: adding route to fd2b:82ee:67b6:1::/64 via fe80::5802:d6da:8d:3db4 Jul 13 17:49:09 UNRAID dhcpcd[1540]: eth0: deleting route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:49:11 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:49:35 UNRAID dhcpcd[1540]: eth0: adding route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:49:35 UNRAID dhcpcd[1540]: eth0: deleting route to fd2b:82ee:67b6:1::/64 via fe80::5802:d6da:8d:3db4 Jul 13 17:49:37 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:49:50 UNRAID dhcpcd[1540]: eth0: deleting route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:49:53 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:52:36 UNRAID dhcpcd[1540]: eth0: adding route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:52:38 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:53:16 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* Jul 13 17:56:10 UNRAID dhcpcd[1540]: eth0: deleting route to 2a03:XXXX:XXXX:402::/64 via fe80::1472:1414:e94e:8303 Jul 13 17:56:12 UNRAID ntpd[1708]: 192.168.88.150 on 1 eth0 -> *multiple* I should note that IPv6 is running smoothly in my home network. My ISP has provided me with a prefix /56. I use the subnet 2a03:XXXX:XXXX:400::/64 for my main network (my UNRAID NAS included). This same subnet is also used for Docker macvlan (host access enabled). However, the log shows constant adding and deleting of the route for 2a03:XXXX:XXXX:402::/64. Does anyone know what might be causing this? I also use the following subnets: 2a03:XXXX:XXXX:401::/64 for Wireguard (running on a MikroTik router) 2a03:XXXX:XXXX:405::/64 for the guest network. Any advice on how to resolve or mitigate this issue would be greatly appreciated. Thank you in advance for your help! unraid-diagnostics-20240714-0015.zip
-
I have checked the uptime of containers and found no crashing.
-
Any idea what's going on? Mar 26 13:48:09 UNRAID dhcpcd[22784]: eth0: adding address fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2/64 Mar 26 13:48:09 UNRAID avahi-daemon[23854]: Registering new address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0.*. Mar 26 13:48:09 UNRAID dhcpcd[22784]: eth0: adding route to fd11:8a45:f39:54d:6700::/64 Mar 26 13:48:15 UNRAID avahi-daemon[23854]: Withdrawing address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0. Mar 26 14:18:11 UNRAID dhcpcd[22784]: eth0: expired address fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2/64 Mar 26 14:18:11 UNRAID dhcpcd[22784]: eth0: part of a Router Advertisement expired Mar 26 14:18:11 UNRAID dhcpcd[22784]: eth0: deleting route to fd11:8a45:f39:54d:6700::/64 Mar 26 15:23:19 UNRAID dhcpcd[22784]: eth0: adding address fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2/64 Mar 26 15:23:19 UNRAID avahi-daemon[23854]: Registering new address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0.*. Mar 26 15:23:19 UNRAID dhcpcd[22784]: eth0: adding route to fd11:8a45:f39:54d:6700::/64 Mar 26 15:23:25 UNRAID avahi-daemon[23854]: Withdrawing address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0. Mar 26 15:35:43 UNRAID avahi-daemon[23854]: Registering new address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0.*. Mar 26 15:44:01 UNRAID avahi-daemon[23854]: Withdrawing address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0. Mar 26 15:44:06 UNRAID avahi-daemon[23854]: Registering new address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0.*. Mar 26 15:45:19 UNRAID avahi-daemon[23854]: Withdrawing address record for fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2 on eth0. Mar 26 16:15:18 UNRAID dhcpcd[22784]: eth0: pid 0 deleted address fd11:8a45:f39:54d:2d0:b4ff:fe02:2cf2/64 Mar 26 16:15:19 UNRAID dhcpcd[22784]: eth0: part of a Router Advertisement expired Mar 26 16:15:19 UNRAID dhcpcd[22784]: eth0: deleting route to fd11:8a45:f39:54d:6700::/64
-
Hi, I have been testing IPv6 for some time and found some issues. Macvlan docker containers cannot communicate with the host via IPv6 although this option is enabled in the docker settings. This works via IPv4. Additionally, once in a while ULA address is assigned to the docker network see below. Mar 24 18:12:10 UNRAID avahi-daemon[9726]: Registering new address record for fd11:8a45:f39:54d:2d0:XXXX:2cf2 on eth0.*. Mar 24 18:13:09 UNRAID avahi-daemon[9726]: Withdrawing address record for fd11:8a45:f39:54d:2d0:XXXX:2cf2 on eth0.Mar 24 18:12:10 UNRAID avahi-daemon[9726]: Registering new address record for fd11:8a45:f39:54d:2d0:XXXX:2cf2 on eth0.*. Mar 24 18:13:09 UNRAID avahi-daemon[9726]: Withdrawing address record for fd11:8a45:f39:54d:2d0:XXXX:2cf2 on eth0. Furthermore, I cannot visit the web UI via https using Ipv6 and myunraid.net (similar link like below). Again IPv4 works and even http via IPv6. https://2a03-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx.mycert.myunraid.net:64443/ Any ideas?
-
Hi, I purchased an ASM1166 sata expansion card, updated the firmware and plugged it into the second m.2 slot (I have a Samsung NVMe SSD in the first m.2 slot). Unfortunately, when ASPM is enabled the pcie port bios settings (used by ASM1166 controller), the UNRAID system does not see any HDDs connected, but C8 states are reached. See the logs below. When I disable ASPM in the BIOS settings for the pcie port that the asm1166 controller is plugged into, UNRAID sees the connected HDDs, but only C3 states are reached. I thought that ASM1166 controller with correct firmware supports ASPM and therefore higher Cstates. Mar 13 22:48:22 UNRAID kernel: ata3: failed to resume link (SControl FFFFFFFF) Mar 13 22:48:22 UNRAID kernel: ata3: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF) Mar 13 22:48:22 UNRAID kernel: ahci 0000:02:00.0: AHCI controller unavailable! Any ideas?
-
Hi, any idea if an intel i226-v prevents higher C-states? Yes, it does.
-
Hi guys, could you please recommend any nvme ssd that supports low power C states? Does not have to be Samsung. Thanks
-
Jellyfin does not have native 2FA support but there is a workaround using Authentik+Duo. VPN is an option as well.
-
Hi, I have recently changed my ISP which supports IPv6 and I have been assigned the /56 prefix by the ISP. I would like to make my NAS including docker containers fully accessible by both protocols. Is it possible for the containers to be able to reach the host via IPv6, the way they can on IPv4. I would almost say it doesn't work via IPv6. By the way, is there any way to prevent the NAS from getting a different IPv6 (not prefix) after each reboot outside of static network settings? What are your recommended practices for IPv6? Thank you
-
In this case, the page won't open using my domain because cannot establish a secure connection in safari. Any idea? I know that adguards DNS rewrites works because my domain is resolved as nextclouds private IP.
-
You mean to set DNS rewrite in AdGuard like this: *.mydomain.com => NPM private IP instead of nextcloud.mydomain.com => nextcloud private IP?
-
ITX motherboards with CPU N100 and N305 finally appeared on aliexpress. I mean the ones with two m.2 slots, 6x SATA ports and 4x 2.5g ethernet ports. https://www.aliexpress.com/item/1005006313184714.html?spm=a2g0o.productlist.main.15.462b24ff0Zl0kN&algo_pvid=d5ac8f21-5945-49b7-9f6a-f4f7aa2fb1f8&algo_exp_id=d5ac8f21-5945-49b7-9f6a-f4f7aa2fb1f8-7&pdp_npi=4%40dis!CZK!10559.58!5279.79!!!457.38!!%40210388c917022402004374163e6632!12000036721962358!sea!CZ!0!AB&curPageLogUid=8NHNEKK0b4OW
-
Hi, I just installed Nextcloud. For external access I use a reverse proxy (NPM) and Cloudflare proxy. Can you please advise me how to set up nextcloud to connect to a server on the local network directly if the communication is through my domain. This way all traffic goes through Cloudflare even though I am on the local network. I use 2x AdGuard Home as my DNS server. I tried rewriting the domain to Nextcloud's private IP address via the DNS rewrite function. However, if I try to connect to the nextcloud server on the local network via my domain in Safari (Mac or iOS), the page won't open with the error - it can't establish a secure connection. An external connection through the domain, however, works fine. What's odd is that if I try to connect through my domain on the local network using the anonymous tab in safari, the nextcloud page loads without a problem. Any idea how to solve this?
-
Hi, In Unraid versions 6.11 (kernel 5.19.17) and 6.12 (6.1.x) on the Gemini Lake CPU architecture, a faulty OpenCL implementation is leading to GPU hangs when Plex attempts hardware-accelerated HDR tone mapping. It's important to note that Plex has verified that the issue is related to Unraid or the kernel's implementation. In contrast, in Unraid version 6.10.3 (kernel 5.15), HW-accelerated HDR tone mapping works without any issues in Plex. This problem has been acknowledged by Plex as stemming from Unraid's implementation or the kernel 5.19.17+. Normal SDR transcoding works perfectly on all versions of Unraid. Oct 25 21:59:27 UNRAID kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out Oct 25 21:59:27 UNRAID kernel: i915 0000:00:02.0: [drm] Plex Transcoder[32177] context reset due to GPU hang Oct 25 21:59:27 UNRAID kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:e757fefe, in Plex Transcoder [32177] See the older logs (v6.11.5) unraid-diagnostics-20230807-2045 2.zip Thank you!
-
Hi, what is the best approach to downgrade from v6.12.4 to 6.10.3? It seems that there is some OpenCL bug with both 6.12 and 6.11 (probably due to kernel implementation). This causes gpu hang when attempting HW HDR tone mapping with Plex. Oct 25 21:59:27 UNRAID kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out Oct 25 21:59:27 UNRAID kernel: i915 0000:00:02.0: [drm] Plex Transcoder[32177] context reset due to GPU hang Oct 25 21:59:27 UNRAID kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:e757fefe, in Plex Transcoder [32177] Thanks for any advice
