June 17, 20233 yr It appears that UnRaid 6.12 is a somewhat buggy mess and this update didn't go well for me at all. I've been forced to revert back to 6.11.5 after multiple issues as I am rather reliant on NFS and need a stable environment. Disabling IPv6 is simply not an option here as my entire network uses it. It seems looking at my logs this may have something to do with it: Jun 18 01:49:27 Pikachu root: Starting NFS server daemons: Jun 18 01:49:27 Pikachu root: /usr/sbin/exportfs -r Jun 18 01:49:27 Pikachu root: /usr/sbin/rpc.nfsd -u -s -H 192.168.2.2 -H 2601:db8:85a3:8d3:1319:8a2e:370:7348 -H 127.0.0.1 -H ::1 8 Jun 18 01:49:27 Pikachu kernel: svc: failed to register nfsdv3 RPC service (errno 111). Jun 18 01:49:27 Pikachu rpc.nfsd[6583]: writing fd to kernel failed: errno 111 (Connection refused) Jun 18 01:49:27 Pikachu rpc.nfsd[6583]: unable to bind AF_INET6 TCP socket: errno 99 (Cannot assign requested address) Jun 18 01:49:27 Pikachu kernel: svc: failed to register nfsdv3 RPC service (errno 111). Jun 18 01:49:27 Pikachu rpc.nfsd[6583]: writing fd to kernel failed: errno 111 (Connection refused) Jun 18 01:49:27 Pikachu kernel: svc: failed to register nfsdv3 RPC service (errno 97). Jun 18 01:49:27 Pikachu rpc.nfsd[6583]: unable to set any sockets for nfsd I note in the logs also there are other services with the same issue: Jun 18 01:49:27 Pikachu root: Starting RPC portmapper: /sbin/rpcbind -w -h 192.168.2.2 -h 2601:db8:85a3:8d3:1319:8a2e:370:7348 Jun 18 01:49:27 Pikachu rpcbind[6576]: cannot bind 2601:db8:85a3:8d3:1319:8a2e:370:7348 on udp6: Cannot assign requested address Jun 18 01:49:27 Pikachu root: Starting RPC NSM (Network Status Monitor): /sbin/rpc.statd Jun 18 01:49:27 Pikachu rpc.statd[6580]: Version 2.6.2 starting Jun 18 01:49:27 Pikachu sm-notify[6581]: Version 2.6.2 starting Jun 18 01:49:27 Pikachu sm-notify[6581]: Already notifying clients; Exiting! Jun 18 01:49:27 Pikachu rpc.statd[6580]: Failed to register (statd, 1, udp): svc_reg() err: RPC: Remote system error - Connection refused Jun 18 01:49:27 Pikachu rpc.statd[6580]: Failed to register (statd, 1, tcp): svc_reg() err: RPC: Remote system error - Connection refused Jun 18 01:49:27 Pikachu rpc.statd[6580]: Failed to register (statd, 1, udp6): svc_reg() err: RPC: Remote system error - Connection refused Jun 18 01:49:27 Pikachu rpc.statd[6580]: Failed to register (statd, 1, tcp6): svc_reg() err: RPC: Remote system error - Connection refused Jun 18 01:49:27 Pikachu rpc.statd[6580]: failed to create RPC listeners, exiting Diagnostics available. I am not really keen to attach this for everyone only due to the potential PII contained within. Let me know if a staffer would like this. The icing on the cake was the WebUI not starting after the upgrade too which appears to be related also:
June 17, 20233 yr If you only complain but don't provide more detailed information (diagnostics), we can't do much. 6.12.0 is a lot strickter and unfortunately people start to discover now incorrect settings from the past. NFS and IPv6 should work. Here is an extract from my log Jun 17 16:50:06 vesta root: Starting NFS server daemons: Jun 17 16:50:06 vesta root: /usr/sbin/exportfs -r Jun 17 16:50:06 vesta root: /usr/sbin/rpc.nfsd -u -s -H 10.0.101.11 -H 2a02:a448:32d5:101:xxxx:xxxx:xxxx:xxxx -H 10.253.0.1 -H 127.0.0.1 -H ::1 8 Jun 17 16:50:07 vesta root: /usr/sbin/rpc.mountd Jun 17 16:50:07 vesta kernel: NFSD: Using UMH upcall client tracking operations. Jun 17 16:50:07 vesta kernel: NFSD: starting 90-second grace period (net f0000000)
June 17, 20233 yr Author I did state that diagnostics are available however unfortunately due to the potential personal information contained within (I see some things I'd much rather not out in the public even in the anonymous zip) I have opted to not post it publicly. I have messaged it to you directly @bonienl.
June 17, 20233 yr You have set up bonding with LACP, but it returns an error. Does your switch support LACP and is it properly configured? Jun 18 01:49:15 Pikachu kernel: br0: received packet on bond0 with own address as source address (addr:5c:ba:2c:25:c4:48, vlan:0) The network error is the reason for not accepting the IPv6 address.
June 17, 20233 yr 17 minutes ago, michaelmurfy said: I see some things I'd much rather not out in the public even in the anonymous zip) Please let us know what should be removed or altered. Always willing to adjust diagnostics and remove private stuff.
June 17, 20233 yr Author 19 minutes ago, bonienl said: You have set up bonding with LACP, but it returns an error. Does your switch support LACP and is it properly configured? Jun 18 01:49:15 Pikachu kernel: br0: received packet on bond0 with own address as source address (addr:5c:ba:2c:25:c4:48, vlan:0) The network error is the reason for not accepting the IPv6 address. Yep - switch (Mikrotik) sure does and is working as expected. I do note sometimes this does show up in the logs however isn't getting absolutely spammed. Switch is detecting a trunk (I have multiple trunks on my network). Same configuration is working no problems on 6.11.5 and switch is also detecting a 4 port LAG for the Microserver. Edited June 17, 20233 yr by michaelmurfy
June 17, 20233 yr Author 9 minutes ago, bonienl said: Please let us know what should be removed or altered. Always willing to adjust diagnostics and remove private stuff. Could be worth masking IPv6 addresses. Despite me having this filtered there are some people who may have their servers exposed over v6 without really knowing. In my case this does expose the /64 subnet the server is on. No biggie, but you know how the internet is with -any form- of Public IP. I have not really looked through the rest to determine if anything else was potentially exposed but as I personally work in security I'd rather go over everything first before posting it.
June 17, 20233 yr 9 minutes ago, michaelmurfy said: Yep - switch (Mikrotik) sure does and is working as expected. As a test you can change the bonding mode to "Active-Standby" as see if the NFS service is able to bind to the interface (this is new in 6.12.0) The error message you receive is because both sides of the bond are initially in different states and the bond acts as a layer 2 connection with one or more loops. It could be a timing issue (perhaps configurable), but I am not familiar with Mikrotik.
June 17, 20233 yr Author So bonding is more for link aggregation in my use-case and not as an active-standby. I do note that error sometimes gets spat out to the syslog but I can't find any reason for it on my network at all. I'm not fully confident this is the sole reason for the issues given the host is getting an IP no problems and the LAG is indeed coming up on the switch: Just to ensure this isn't potentially caused by a switching loop I did check the STP/IGMP configuration of all my switches etc. Good catch though, I am seeing this pop up quite a bit in the logs and am rather miffed with what it may be... It is not getting absolutely spammed (there is a fair bit of traffic that goes to this server) but is getting spammed enough... I'll take a look at it more when it isn't 4am.
June 17, 20233 yr 8 minutes ago, michaelmurfy said: I'm not fully confident this is the sole reason for the issues given the host is getting an IP IPv6 works a bit different and doesn't like loops (it is doing multicast). As I said, change the bonding mode for testing purposes, it will give you a better view what to look for.
June 18, 20233 yr Author That appears to be a red herring - I fixed the issue above in regards to the network bond but if IPv6 gets assigned I get no nginx, nfs and other services start at all (and this round I couldn't get nginx to even start to grab a diagnostics dump so pulled /var/syslog instead) If I disable "Flood Unknown Multicast" on my switch it'll break IPv6 but things start up fine even with a network bond. I then disabled bonding entirely going back to a single Gigabit ethernet port with nothing special - server gets an IPv6 prefix but web interface, nfs etc doesn't start. When this happens I can't get a diagnostics file as the web interface simply refuses to start. Let me know if I can grab any other files of any use. Note also - IPv6 works no problems on 6.11.5 despite the odd "own address as source address" syslog entry before. I've attached the syslog files here both with and without 802.3ad LACP enabled. Just to make things easier and to ensure there were absolutely no issues I reduced the ethernet ports down to a single port during testing. Also on a network configuration change in UnRaid (IPv4 only) I note this gets spit out in the syslog - I did try the old trick of "change anything in network settings" as part of troubleshooting: Message from syslogd@Pikachu at Jun 18 14:52:44 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to 0.0.0.0:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:44 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to [::]:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:45 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to 0.0.0.0:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:45 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to [::]:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:45 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to 0.0.0.0:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:45 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to [::]:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:46 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to 0.0.0.0:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:46 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to [::]:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:46 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to 0.0.0.0:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:46 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: bind() to [::]:443 failed (98: Address already in use) Message from syslogd@Pikachu at Jun 18 14:52:47 ... nginx: 2023/06/18 14:52:44 [emerg] 6324#6324: still could not bind() So I don't think this is a network problem. IPv6 works, and I use it for everything internally but just not on 6.12. I have to downgrade back to restore service fully but let me know if there is anything else you'd like me to try. I can't just take everything down anytime though I'm afraid and need to ensure nobody else is using the server. syslog-dump.7z
June 18, 20233 yr I made several fixes and improvements for the next release. Perhaps you can try it when it becomes available (soon)
June 23, 20233 yr Author @bonienl 6.12.1 didn't fix this issue just FYI. Full working V6 on 6.11.5 but web interface and services still fail to start with 6.12.1... Log attached. Note, there is the above error but that has been proven to be a red herring and does show up in the syslog here. Let me know if there is anything else I can grab to assist - also note the web interface doesn't work at all nor can I get it started. syslog-6.12.1
June 23, 20233 yr None of the services can bind to the IPv6 address (I x'd the address) Jun 24 01:02:35 Pikachu sshd[1764]: error: Bind to port 22 on 2406:e001:1:df07:5ebb:2cff:xxxx:xxxx failed: Cannot assign requested address. Jun 24 01:02:37 Pikachu ntpd[1797]: bind(22) AF_INET6 2406:e001:1:df07:5ebb:2cff:xxxx:xxxx#123 flags 0x11 failed: Cannot assign requested address Jun 24 01:02:54 Pikachu rpcbind[6026]: cannot bind 2406:e001:1:df07:5ebb:2cff:xxxx:xxxx on udp6: Cannot assign requested address Jun 24 01:02:56 Pikachu nginx: 2023/06/24 01:02:56 [emerg] 6198#6198: bind() to [2406:e001:1:df07:5ebb:2cff:xxxx:xxxx]:80 failed (99: Cannot assign requested address) DHCP is also complaining about not getting an IPv6 address Jun 24 01:02:35 Pikachu rc.inet1: can't obtain IP address, continue polling in background on interface br0 Jun 24 01:02:35 Pikachu rc.inet1: dhcpcd -b -q -n -t 10 -h Pikachu -6 br0 Do have any lines in your go file or somewhere else which disables IPv6? I would need diagnostics to see more details
June 23, 20233 yr One more observation: your system gets initially an IPv4 link local address (169.254.xxx.xxx). Upcoming version 6.12.2 addresses this situation.
June 24, 20233 yr Author Simply got this in my go file: #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & # Set TLER on the shucked drives. /usr/bin/python3 /boot/config/set_tler.py /bin/bash /boot/config/ssh/setup_ssh_client.sh # Write Cache hdparm -W 1 /dev/sdf hdparm -W 1 /dev/sde hdparm -W 1 /dev/sdc hdparm -W 1 /dev/sdd Nothing for IPv6 anywhere. Router allocates IPv6 via SLAAC to the network. Afraid I can't grab the diagnostics in this state but I did grab the diagnostics before I restored (with V4 only). Flicked to your private message seeing this one isn't the anonymous one.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.