ljm42

VPNs like this add a major layer of complication. If you are connected over an encrypted VPN tunnel there is no need for https. Just use http://ipaddress (if "Use SSL" is set to no) or https://ipaddress (if "Use SSL" is set to yes. In this case you will also need to ignore the browser warnings) Docker containers are not proxied through Unraid, so Unraid's certificate has no bearing on a container's certificate. You'd want to ask for help in the forum thread for that docker container. Now I'm confused : ) what is the "it" that we are talking about here?

This should help: https://unraid.net/blog/zfs-guide

Using SSH or a keyboard/monitor plugged directly into the server, please type these two commands to be sure nginx is fully stopped: /etc/rc.d/rc.nginx stop ps -ef | grep "nginx" | grep -v "grep" If that second command returns anything at all type these two commands: /etc/rc.d/rc.nginx term ps -ef | grep "nginx" | grep -v "grep" Now that second command should not return anything. Then type: /etc/rc.d/rc.nginx start and copy/paste everything back here so I can see what happened. Then try accessing the webgui via this url; http://192.168.1.145:8880 If it fails, what error message do you get?

Glad you are up and running! One thing I will say for anyone following along, I'd recommend updating to 6.12.4 first, before making any changes to the Docker config. The new settings have no effect on older releases so there is no added value in changing things before upgrading. Also, if your goal is to use IPVLAN then don't disable bridging. When you disable bridging the system uses a macvtap network with macvlan, which was the main reason for the 6.12.4 release : )

@wayner I moved your posts to your own thread: https://forums.unraid.net/topic/145106-call-traces-in-6124/#comment-1305873

Sorry for the trouble. But that issue is completely unrelated to the current thread : ) You might want to keep an eye on this thread, I think it is the same: https://forums.unraid.net/bug-reports/stable-releases/6124-unable-to-start-dockers-with-custom-ipv6-address-r2667/

Your system is getting call traces, and they implicate macvlan. Bridging is still enabled so it doesn't look like you've made the changes recommended for 6.12.4? Note that upgrading to 6.12.4 is not enough, you need to read the release notes and make some changes in order to avoid call traces and the eventual crash they cause For most systems, switching from macvlan to ipvlan is the simplest option and is a good place to start. If you later discover your Ubiquity isn't doing everything you want, then you can investigate the other option mentioned in the release notes. This may help too: https://forums.unraid.net/topic/144798-ipvlan-unifi-need-help-understanding-this-statement/#comment-1304184 If you continue having issues, please start a new thread. This thread is specifically for people who want to use two NICs to avoid the call traces. It is still a viable solution, but in 6.12.4 there is a better way. NVM I moved all your posts to a new thread Edit: sorry I updated this reply a few times. Think I'm done now : )

The syslog has multiple call traces that look like this: Sep 10 22:38:04 Tower kernel: Call Trace: Sep 10 22:38:04 Tower kernel: <IRQ> Sep 10 22:38:04 Tower kernel: dump_stack_lvl+0x44/0x5c Sep 10 22:38:04 Tower kernel: __report_bad_irq+0x35/0xaa Sep 10 22:38:04 Tower kernel: note_interrupt+0x1f6/0x24d Sep 10 22:38:04 Tower kernel: handle_irq_event_percpu+0x2c/0x35 Sep 10 22:38:04 Tower kernel: handle_irq_event+0x37/0x56 Sep 10 22:38:04 Tower kernel: handle_fasteoi_irq+0x99/0x113 Sep 10 22:38:04 Tower kernel: __common_interrupt+0x9e/0xaa Sep 10 22:38:04 Tower kernel: common_interrupt+0x96/0xc1 Sep 10 22:38:04 Tower kernel: </IRQ> Sep 10 22:38:04 Tower kernel: <TASK> Sep 10 22:38:04 Tower kernel: asm_common_interrupt+0x22/0x40 Sep 10 22:38:04 Tower kernel: RIP: 0010:cpuidle_enter_state+0x11d/0x202 Sep 10 22:38:04 Tower kernel: Code: 20 22 a0 ff 45 84 ff 74 1b 9c 58 0f 1f 40 00 0f ba e0 09 73 08 0f 0b fa 0f 1f 44 00 00 31 ff e8 4c e3 a4 ff fb 0f 1f 44 00 00 <45> 85 e4 0f 88 ba 00 00 00 48 8b 04 24 49 63 cc 48 6b d1 68 49 29 Sep 10 22:38:04 Tower kernel: RSP: 0000:ffffc900000dbe98 EFLAGS: 00000282 Sep 10 22:38:04 Tower kernel: RAX: 0000000000000000 RBX: ffff888353bf6300 RCX: 0000000000000020 Sep 10 22:38:04 Tower kernel: RDX: 00000000820ed4af RSI: 000000007fffffff RDI: 00000000ffffffff Sep 10 22:38:04 Tower kernel: RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000000002 Sep 10 22:38:04 Tower kernel: R10: 0000000000000020 R11: 0000000000000004 R12: 0000000000000004 Sep 10 22:38:04 Tower kernel: R13: ffffffff823205c0 R14: 000000010624b113 R15: 0000000000000001 Sep 10 22:38:04 Tower kernel: ? cpuidle_enter_state+0x117/0x202 Sep 10 22:38:04 Tower kernel: cpuidle_enter+0x2a/0x38 Sep 10 22:38:04 Tower kernel: do_idle+0x18d/0x1fb Sep 10 22:38:04 Tower kernel: cpu_startup_entry+0x1d/0x1f Sep 10 22:38:04 Tower kernel: start_secondary+0x101/0x101 Sep 10 22:38:04 Tower kernel: secondary_startup_64_no_verify+0xce/0xdb Sep 10 22:38:04 Tower kernel: </TASK> Sep 10 22:38:04 Tower kernel: handlers: Sep 10 22:38:04 Tower kernel: [<(____ptrval____)>] usb_hcd_irq Sep 10 22:38:04 Tower kernel: [<(____ptrval____)>] usb_hcd_irq Those do not look like normal "call traces related to macvlan". But it wouldn't hurt to switch from macvlan to ipvlan anyway, see https://docs.unraid.net/unraid-os/release-notes/6.12.4/#fix-for-macvlan-call-traces

I'd start with this note from Fix Common Problems: It looks like eth0 gets 10.1.1.20 from DHCP and eth2 is statically assigned 10.1.1.115. That confuses IP networking because there are two ways for the system to get to the 10.1.1.1 gateway. More info here: https://forums.unraid.net/topic/120220-fix-common-problems-more-information/page/2/#comment-1100014

Fixes for call traces and crashes related to macvlan are the main reason for this release. A config change is needed, you'll want to read the release notes for details.

As far as the VM is concerned, it works exactly the same whether it is on the bridge network or the macvtap network. The VM template assigns the VM a mac address, and the VM can use that to get a DHCP address from the router, or the VM can assign itself a static IP. Unraid is not and has never been directly involved in the IP assignment for a VM. As mentioned in the release notes, make sure the VM template is set to vhost0 and not br0. And make sure Host access to custom networks is enabled (assuming you want that)

The intent is that if there is room for three columns there will be three columns, if there isn't room then there won't be. The one exception to this is if while customizing the dashboard you remove all tiles from a given column, then that column is deleted. In that case, to restore the missing column, unlock the page and click the wrench icon, then reset your tiles. Note that in previous versions of Unraid the columns were different sizes, and wider tiles were restricted to wider columns. Because tiles can now go in any column, all columns are now the same (wider) size and that may result in there only being room for two columns where there were previously three.

ipvlan works well on most networks, and there is no way the system can crash due to macvlan when configured for ipvlan. It is a good default, I'd recommend starting there. However, if you have issues with port forwarding (so far only reported by users with a Fritzbox) then you'll want to use macvlan. Network access works fine in Ubiquity but some users don't like that when ipvlan is enabled, Ubiquity can no longer show Docker containers on custom networks with their own entry in graphs/tables/etc. If that is a critical feature for you then you'll want to use macvlan. My suggestion would be to confirm the system is stable with ipvlan and then decide if you want to make any changes.

yes

Agreed. Thanks for this report @hawihoney So this has been the intended behavior for a long time, but due to a bug it was not actually working as intended. That bug was recently fixed and now it is clear that the intended behavior it is not actually what we want. This will be fixed in 6.13 to run regardless of whether User Shares are enabled or not.

update_cron is called by Unraid to enable `mover`, but User Shares are disabled on this server so `mover` is not needed. If you enable User Shares then update_cron will be run when the array starts https://docs.unraid.net/unraid-os/manual/shares/user-shares/

Also, the system has call traces related to macvlan, you'll want to read the 6.12.4 release notes for a fix: https://forums.unraid.net/topic/144429-unraid-os-version-6124-available/

This was in the first set of diags (logs\syslog.txt) you uploaded: Sep 3 04:55:41 oxygen kernel: BUG: kernel NULL pointer dereference, address: 00000000000000b6 Sep 3 04:55:41 oxygen kernel: #PF: supervisor read access in kernel mode Sep 3 04:55:41 oxygen kernel: #PF: error_code(0x0000) - not-present page Sep 3 04:55:41 oxygen kernel: PGD 0 P4D 0 Sep 3 04:55:41 oxygen kernel: Oops: 0000 [#1] PREEMPT SMP PTI Sep 3 04:55:41 oxygen kernel: CPU: 5 PID: 29553 Comm: deluged Tainted: P O 6.1.49-Unraid #1 Sep 3 04:55:41 oxygen kernel: Hardware name: ASUS All Series/MAXIMUS VII HERO, BIOS 3503 04/18/2018 Sep 3 04:55:41 oxygen kernel: RIP: 0010:folio_try_get_rcu+0x0/0x21 Sep 3 04:55:41 oxygen kernel: Code: e8 13 50 6b 00 48 8b 84 24 80 00 00 00 65 48 2b 04 25 28 00 00 00 74 05 e8 19 8c 6c 00 48 81 c4 88 00 00 00 5b c3 cc cc cc cc <8b> 57 34 85 d2 74 10 8d 4a 01 89 d0 f0 0f b1 4f 34 74 04 89 c2 eb Sep 3 04:55:41 oxygen kernel: RSP: 0000:ffffc9000b2efca0 EFLAGS: 00010246 Sep 3 04:55:41 oxygen kernel: RAX: 0000000000000082 RBX: 0000000000000082 RCX: 0000000000000082 Sep 3 04:55:41 oxygen kernel: RDX: 0000000000000001 RSI: ffff88831ad34db0 RDI: 0000000000000082 Sep 3 04:55:41 oxygen kernel: RBP: 0000000000000000 R08: 0000000000000024 R09: ffffc9000b2efcb0 Sep 3 04:55:41 oxygen kernel: R10: ffffc9000b2efcb0 R11: ffffc9000b2efd38 R12: 0000000000000000 Sep 3 04:55:41 oxygen kernel: R13: ffff888532563aa8 R14: 0000000000160725 R15: ffff888532563ab0 Sep 3 04:55:41 oxygen kernel: FS: 00001521669fd6c0(0000) GS:ffff88880fb40000(0000) knlGS:0000000000000000 Sep 3 04:55:41 oxygen kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 3 04:55:41 oxygen kernel: CR2: 00000000000000b6 CR3: 000000045e8bc001 CR4: 00000000001706e0 Sep 3 04:55:41 oxygen kernel: Call Trace: Sep 3 04:55:41 oxygen kernel: <TASK> Sep 3 04:55:41 oxygen kernel: ? __die_body+0x1a/0x5c Sep 3 04:55:41 oxygen kernel: ? page_fault_oops+0x329/0x376 Sep 3 04:55:41 oxygen kernel: ? fixup_exception+0x22/0x24b Sep 3 04:55:41 oxygen kernel: ? exc_page_fault+0xfb/0x11d Sep 3 04:55:41 oxygen kernel: ? asm_exc_page_fault+0x22/0x30 Sep 3 04:55:41 oxygen kernel: ? dio_warn_stale_pagecache.part.0+0x95/0x95 Sep 3 04:55:41 oxygen kernel: __filemap_get_folio+0x98/0x213 Sep 3 04:55:41 oxygen kernel: filemap_fault+0x6b/0x52f Sep 3 04:55:41 oxygen kernel: ? preempt_latency_start+0x1e/0x46 Sep 3 04:55:41 oxygen kernel: __do_fault+0x2d/0x6b Sep 3 04:55:41 oxygen kernel: __handle_mm_fault+0xa22/0xcf9 Sep 3 04:55:41 oxygen kernel: handle_mm_fault+0x13d/0x20f Sep 3 04:55:41 oxygen kernel: do_user_addr_fault+0x2c3/0x48d Sep 3 04:55:41 oxygen kernel: exc_page_fault+0xfb/0x11d Sep 3 04:55:41 oxygen kernel: asm_exc_page_fault+0x22/0x30 Sep 3 04:55:41 oxygen kernel: RIP: 0033:0x152338b6cb0d Sep 3 04:55:41 oxygen kernel: Code: 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 83 fa 20 72 23 <c5> fe 6f 06 48 83 fa 40 0f 87 a5 00 00 00 c5 fe 6f 4c 16 e0 c5 fe Sep 3 04:55:41 oxygen kernel: RSP: 002b:00001521669fc898 EFLAGS: 00010202 Sep 3 04:55:41 oxygen kernel: RAX: 0000152104004510 RBX: 0000152104000b90 RCX: 00001521669fcac0 Sep 3 04:55:41 oxygen kernel: RDX: 0000000000004000 RSI: 0000152053325bce RDI: 0000152104004510 Sep 3 04:55:41 oxygen kernel: RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 Sep 3 04:55:41 oxygen kernel: R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000 Sep 3 04:55:41 oxygen kernel: R13: 0000152104002460 R14: 0000000000000002 R15: 0000000160725bce Sep 3 04:55:41 oxygen kernel: </TASK> Sep 3 04:55:41 oxygen kernel: Modules linked in: tun nvidia_uvm(PO) veth xt_nat xt_tcpudp xt_conntrack nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype br_netfilter bridge xfs md_mod zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) tcp_diag inet_diag jc42 regmap_i2c iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha ip6table_filter ip6_tables iptable_filter ip_tables x_tables efivarfs af_packet 8021q garp mrp stp llc macvtap macvlan tap intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp nvidia_drm(PO) nvidia_modeset(PO) kvm_intel i915 kvm nvidia(PO) iosf_mbi drm_buddy i2c_algo_bit ttm drm_display_helper crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel sha512_ssse3 drm_kms_helper aesni_intel crypto_simd cryptd drm rapl mei_hdcp mei_pxp intel_gtt Sep 3 04:55:41 oxygen kernel: intel_cstate nvme wmi_bmof mxm_wmi agpgart mei_me intel_uncore syscopyarea i2c_i801 sysfillrect ahci i2c_smbus sysimgblt e1000e i2c_core mei libahci nvme_core fb_sys_fops thermal fan video wmi backlight button acpi_pad unix Sep 3 04:55:41 oxygen kernel: CR2: 00000000000000b6 Sep 3 04:55:41 oxygen kernel: ---[ end trace 0000000000000000 ]--- Sep 3 04:55:41 oxygen kernel: RIP: 0010:folio_try_get_rcu+0x0/0x21 Sep 3 04:55:41 oxygen kernel: Code: e8 13 50 6b 00 48 8b 84 24 80 00 00 00 65 48 2b 04 25 28 00 00 00 74 05 e8 19 8c 6c 00 48 81 c4 88 00 00 00 5b c3 cc cc cc cc <8b> 57 34 85 d2 74 10 8d 4a 01 89 d0 f0 0f b1 4f 34 74 04 89 c2 eb Sep 3 04:55:41 oxygen kernel: RSP: 0000:ffffc9000b2efca0 EFLAGS: 00010246 Sep 3 04:55:41 oxygen kernel: RAX: 0000000000000082 RBX: 0000000000000082 RCX: 0000000000000082 Sep 3 04:55:41 oxygen kernel: RDX: 0000000000000001 RSI: ffff88831ad34db0 RDI: 0000000000000082 Sep 3 04:55:41 oxygen kernel: RBP: 0000000000000000 R08: 0000000000000024 R09: ffffc9000b2efcb0 Sep 3 04:55:41 oxygen kernel: R10: ffffc9000b2efcb0 R11: ffffc9000b2efd38 R12: 0000000000000000 Sep 3 04:55:41 oxygen kernel: R13: ffff888532563aa8 R14: 0000000000160725 R15: ffff888532563ab0 Sep 3 04:55:41 oxygen kernel: FS: 00001521669fd6c0(0000) GS:ffff88880fb40000(0000) knlGS:0000000000

I can't reproduce this on any of my systems (bare metal or VM) but I agree the command is missing from your logs. Looking into it, although still open to ideas from other folks : )

The system is still getting call traces. If you are fine with ipvlan, please do this: * Settings > Network Settings > eth0 > Enable Bridging = Yes * Settings > Docker > Docker custom network type = ipvlan (then reboot)

I have a feeling you might be right here. Will somebody who is running 6.12.4 please provide diagnostics after a reboot, after the container is started, but before you manually re-edit the listening interfaces. i.e. the listening interfaces should have the correct values from a previous boot, but I want logs that show they are ignored. Thanks!

Yeah, adding it to Tools > Update OS is just the first step. We'll deal with the banner in the future.

@TheDon thanks for the diagnostics, but I moved your post to its own thread since it looks like it will take more back and forth than makes sense in a release thread:

reload the page : )

FWIW, this was an issue that happened when shutting down 6.12.3, it was not related to the upgrade to 6.12.4. The upgrade changes the files on the flash drive, it does not change the running system. So applying an upgrade will have no effect on whether the running system is able to shutdown properly. i.e. the unclean shutdown likely would have happened the next time you rebooted, regardless of whether an upgrade was involved or not. Please see this thread for more discussion and a recommendation: https://forums.unraid.net/topic/144649-6123-unclean-shutdown/#comment-1302638 I don't know why your systems had this issue. It would be helpful if you check the logs folder on your flash drive for diagnostics with the right date and upload them to that thread so I can look for clues.