ljm42

Ah, it was not clear that you were rebooting between attempts. OK that is good. Please edit your message to delete all those individual files and upload the zip as a single file instead. I understand Macs can make this type of thing difficult. If you are choosing random ports, please use something higher than 1000 and lower than 64,000, and make sure it isn't already in use by a Docker container. Based on that screenshot it looks like nginx is running fine. What error message do you get when you try to access the webgui? Sometimes browsers will assume https, but you are trying to use http. So be sure you type "http" at the beginning of the address: http://192.168.4.41 or http://192.168.4.41:port in the browser's url bar

Hi @itimpi would you please remove HTML from the notifications from the Parity Check Tuning plugin? They are meant to be text only. I'd suggest using markdown formatting instead. I'm not sure if markdown in notifications would be rendered as html in the webgui, but markdown itself is pretty readable. This will prevent issues with emails that are sent as well as with notification agents that aren't expecting to get HTML.

According to your diags the ports nginx is trying to use are: PORT="80" PORTSSL="443" If you changed them to something else in config/ident.cfg, be sure to include the port when trying to access the webgui. Can you give more info on what you did here? Until you reboot, changing this setting in config/docker.cfg won't have any effect. To stop docker without rebooting, you can type this via SSH: /etc/rc.d/rc.docker stop but before doing that... I think nginx is not stopping properly, which means it can't restart properly. Please connect via SSH and type: /etc/rc.d/rc.nginx term followed by /etc/rc.d/rc.nginx start and paste the output of both commands back here. If this doesn't solve the problem, please provide updated diagnostics as well (type "diagnostics" and then grab the latest zip from the logs directory on the flash drive)

With the Dynamic options, remote access is disabled until you use the Connect Dashboard to enable it when needed. In your screenshot, clicking on the blue "Connect Dashboard" link will take you to the Connect Dashboard here: https://connect.myunraid.net/ Once signed in there, go to your server's details and click Start Remote Access For more info about the Remote Access features of Connect, see the docs here: https://docs.unraid.net/connect/remote-access/

What URL are you trying to use? What error message are you getting? Note that your myunraid.net url will not work because DNS Rebinding Protection is enabled on your network. Based on your current settings I would expect these to work: https://r620.local:5978 https://192.168.178.83:5978 If not, when signed in via ssh type `use_ssl no` and then try accessing: http://192.168.178.83:5975 That hasn't been updated in a while, you can try deleting config/plugins/theme.engine.plg from your flash drive and rebooting.

Oh I see the issue. Edit config/ident.cfg on the flash drive. Find this line: PORTSSL="88443" 88443 is too big, change that to a number between 1000 and 64000 Then run /etc/rc.d/rc.nginx start

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 setting up that container in the forum thread for that container. The local TLD is used for URLS, such as: http://server.local https://server.local The https url will use a self-signed certificate which causes browser warnings. But other than that it is fine. If you had your own domain you could enter "mydomain.com" in that field and then the urls would be: http://server.mydomain https://server.mydomain This also requires you to have DNS and provide your own certificate. More details in the docs provided earlier Separate from that, once you provision a myunraid certificate you can access the server via a unique myunraid.net url using a valid certificate that we provide.

It seems that you are trying both fixes from the release notes rather than just one: Fix 1: change macvlan to ipvlan. If you are happy with that then you are done. Fix 2: if you want to use macvlan then disable bridging. This removes the option for ipvlan and always enables macvlan At this point you are using the second fix. That is fine. I modified the release notes to try and make it more clear that if you change macvlan to ipvlan, you are done! No more changes needed. If bonding is enabled you will see bond0, if bonding is disabled you will see eth0. Either works fine.

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

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

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)