ljm42
-
Posts
4,406 -
Joined
-
Last visited
-
Days Won
27
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by ljm42
-
-
9 minutes ago, dfwjensen said:
Still getting an HTTP 500 error.
aha! a 500 error means that nginx is responding to requests.
via SSH, type
ls -al /var/log/nginx/This will show how big the nginx error log is.
Then type:
cat /var/log/nginx/error.logto see the error messages and paste the results back here.
-
Glad things are working well for you!
Looks like you went with the "2-nic docker segmentation method", that prevents macvlan call traces because it avoids bridging on the nic that is running Docker.
The downside is that it requires two nics, and it is a little more complicated than I would want all users to have to go through.
For other folks, 6.12.4 has a one-click solution that only needs a single nic, but if you are happy using two nics then there is no reason to change anything.
-
25 minutes ago, itimpi said:
I DID use markdown 😊. That allowed me to bolden part of the notification when displayed via the web GUI. It is obviously not being passed through transparently to the other notification agents. I can remove it but it is a shame that I need to 😒
Interesting : )
When I pass markdown to the notify script directly:
/usr/local/emhttp/webGui/scripts/notify -e "My Event" -s "My Subject" -d 'See **Troubleshooting** section of online documentation for guidance on resolving this' -m "My Message" -i "alert" -l "/Dashboard"It comes through the email as markdown, so I'm pretty confident the notification system is not converting it to HTML
I see where you are defining the string using markdown as `**Troubleshooting**`:
But I think something (maybe the translation system?) is converting the markdown to HTML before it is passed to to the notify script
-
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.
41 minutes ago, dfwjensen said:I tried both port 88 and 247. Then rebooted the server and tried to access via 192.168.4.41:88 or :247 with no luck.
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.
41 minutes ago, dfwjensen said:Then rebooted the server and tried to access via 192.168.4.41:88 or :247 with no luck.
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.
-
5 hours ago, dfwjensen said:
I tried two different random ports, but still can't connect.
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.
5 hours ago, dfwjensen said:Also tried disabling the docker start in the config.
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 stopbut 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 termfollowed by
/etc/rc.d/rc.nginx startand 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:
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/
-
On 9/12/2023 at 9:50 AM, aLinuxFreak said:
I cannot acces the WebUI anymore
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:5978If not, when signed in via ssh type `use_ssl no` and then try accessing:
http://192.168.178.83:5975
On 9/12/2023 at 9:50 AM, aLinuxFreak said:i also had Theme Engine installed.
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 -
8 hours ago, Braulio said:
It = docker Vaultwarden
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.
8 hours ago, Braulio said:I'm confused about how it [Local TLD] works
The local TLD is used for URLS, such as:
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:
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.
-
1
-
-
21 hours ago, wayner said:
I wasn't sure exactly what changes to make so I hadn't made any yet. I have now changed to ipvlan, Set Bridging to No, and kept Bonding at Yes. Dockers were already set to allow Custom Networks.
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.
21 hours ago, wayner said:My dockers are now using bond0 as the custom network interface. I do not have an option to user eth0. Is that OK?
If bonding is enabled you will see bond0, if bonding is disabled you will see eth0. Either works fine.
-
10 hours ago, Braulio said:
2) VPN
My difficulty is that I'm using ZeroTier, and when I access it through option A or B it doesn't connect through SSL.
Even using option A doesn't connect https , because the network's IP changes https://my_ip_zerotier.my_id.myunraid.netVPNs 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)
10 hours ago, Braulio said:3) Docker Vaultwarden
I installed this docker and it won't let me connect to webUI without a secure connection (https)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.
10 hours ago, Braulio said:4) I can't figure out why it works via https (SSL).
I'm asking for help again because I'm a little confused and lost.Now I'm confused : ) what is the "it" that we are talking about here?
-
This should help: https://unraid.net/blog/zfs-guide
-
3 hours ago, mercury3000 said:
I found out that NGINX isn't working and whenever I try "/etc/rc.d/rc.nginx reload" or "/etc/rc.d/rc.nginx restart", the status always shows: "NGINX IS NOT RUNNING"
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 startand 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?
-
5 hours ago, nka said:
I just want to say that I've upgrade to 6.12.4 from 6.11.5 and it has been stable for me (6.12.2 was freezing every day, I do have 1 days and 6 hours now).
Processus was :
- Take note of all IP of Dockers using br0 (already have them, but just in case).
- Disable Dockers.
- Disable Network Bridge in Network Setting.
- Back to Dockers settings to change from macvlan to ipvlan.
- Enable Docker (and let them start).
- Update all br0 dockers to eth0 (or VLAN) and set old IP again.
- Disable Docker.
- Update to 6.12.4.
- Reboot.
- Enable Docker.
Thanks!
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
-
7 hours ago, maximushugus said:
After upgading, I cannot use IPV6 for my containers.
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:
-
1
-
-
2 hours ago, wayner said:
OK thanks. Perhaps FCP is warning me about old errors that are no longer present since I upgraded to 6.12.4? But my system has only been up and running for 16 hours. But FCP gives my five occurrences of "macvlan call traces found" that would indicate errors. But I don't see anything in my log about macvlan call traces found other than those Call Trace issues shown above or entries generated by FCP. And they show up in red.
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
QuoteWhat sort of reduced functionality is this referring to? And does this affect all Ubiquiti users or some?
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:
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 threadEdit: 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-
1
-
-
I'd start with this note from Fix Common Problems:
QuoteSep 12 08:18:10 Tower root: Fix Common Problems: Error: Multiple NICs on the same IPv4 network ** Ignored
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 -
6 hours ago, nka said:
Does 6.12.4 still crashing? I reverted back to 6.11.5 because 6.12.2 was freezing all the time.
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.
-
9 minutes ago, ConnerVT said:
Correct, you don't need bridging to run a VM. But the question here is (which will help the person you replied to as well as myself):
With 6.12.4, macvlan, and no bridging, how do you access the VM from outside of the Unraid dash board?
There does not seem to be an identifiable IP address which can be seen on the same subnet which the LAN network is configured (192.168.122.0/24 vs 192.168.1.0/24 for the LAN).
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)
-
1
-
-
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.
-
1
-
WebGUI after reboot no longer loads/connects
in General Support
Posted
I am kind of stumped. So you are getting a 500 error but nothing is logged in syslog or errors.log.
Is Docker currently disabled? If not, please disable it and reboot. I just want to make sure there is not a Docker container responding on port 80.