ElectricBadger

@JorgeB Thanks — that's fixed it! Bizarre that the other two VMs were getting the right IP address despite appearing to use virbr0, but now that I've enabled bridging on the interface, they seem to have changed to br0 without any manual intervention! I wonder if they were using bridging all along?

Thanks — both are network source virbr0, and network model virtio-net. I don't even have br0 in the list!

My local network is 192.168.69.*, with the Unraid server at 192.168.69.99. The DHCP server is a Pi-hole at 192.168.69.13. I recently tried to set up a new VM, only to find that it could not see the network. I found that Unraid had created something at 192.168.122.1, and was running its own DHCP server on that, meaning the VM was getting an IP address of 192.168.122.196 and could not see or be seen by anything else. I changed my Mac's subnet mask to 255.255.0.0 so I could see what was going on, and nmap found that 192.168.122.1 was exposing the same ports as 192.168.69.99's VMs — I could VNC into each one. Existing VMs behave correctly, and I can't see anything in the new VM setup that tells Unraid to do this. How do I stop Unraid from trying to be a DHCP server? I have a DHCP server, and a second one on some random subnet just breaks things!

Far too many links in unRAID don't behave like normal links: if you click them, they open in the same tab; if you ⌘-click (or ctrl-click if not on Mac) then they open in a new tab. Example: On the Docker page, ⌘-click Settings. Expected behaviour: a new tab opens containing the Settings page. The original tab is still on the Docker page. Actual behaviour: both tabs are on the Settings page, because the source for the Settings link is this: <a href="/Settings" onclick="initab('/Settings')">Settings</a> I don't know what initab does, but given the new tab (which is opened by the href and ignores the onclick) seems to work just fine, then it doesn't seem to be particularly necessary. Another example: Click on Apps, and click on the Support button for any app. Click on the Support Forum link. Expected behaviour: it opens in the same tab. If I want to open it in a new tab, I can ⌘-click it to use the standard browser behaviour. If I want to open it in a different browser, I can right-click on it and choose Copy Link Address. Actual behaviour: it opens in a new tab, because it has target="_blank" set, despite my not having been asked if I want this behaviour by default, and not having any way to turn it off. I cannot right-click to copy the link in order to open it in the same tab (or a different window from the one the current tab is in, or a different browser) because unRAID disables right-click on this menu even though it works on other page elements. WHY? SummaryunRAID should not assume how people want to use links; it should just use standard <a href="whatever"> without JavaScript overrides and without target="_blank". I'm fairly sure unRAID users are advanced enough to know about the modifier key to open a link in a new tab if they want it there. But there is no modifier key for "ignore the target attribute and open in this tab"…

I'm very confused by all of this. I already know there are multiple sites with man pages online, and that's of no use to me when I'm using ssh to access unRAID. I just want to type man command like on every other Unix-based system and have it work. I don't want to have to manually build man pages — I want unRAID to have an option to include them, and then have it do all the legwork for me. That's why I posted this in the Feature Requests forum — in the hope of getting an "include manpages" checkbox somewhere under Settings 🙂

Thanks — there seems to be something I'm missing, though. Install by pasting https://raw.githubusercontent.com/ich777/un-get/master/un-get.plg into the manual install plugin page (you'd think this would be documented in the plugin's README, but it isn't…) Type un-get update Type un-get install mandb man-pages groff Get error Can't find package(s): mandb! Do I need to add something to the sources.list in order to do this?

10 seconds. Yes, no wonder it was causing problems. Thanks!

Is there a way to use this with containers that use SQLite, such as Sonarr or Radarr, without it causing their databases to be corrupted when it stops the container? (Running a backup without stopping the container, obviously — but that's not ideal as the backup could be corrupted!) Unfortunately, whatever method is used to stop the container doesn't seem to wait long enough for Radarr to finish before abruptly terminating the container mid-operation. (It's also possible that Radarr doesn't spot that it's being asked to shut down gracefully and just rampages on until it gets killed…)

ScenarioI want to use the "find" command to find all files in a folder older than 6 months. ProblemI can't remember the correct syntax. Actual behaviourI type "man find" and get "man: command not found". I type "find --help" and get this, which is not helpful: Tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N -cnewer FILE -context CONTEXT -ctime N -empty -false -fstype TYPE -gid N -group NAME -ilname PATTERN -iname PATTERN -inum N -iwholename PATTERN -iregex PATTERN -links N -lname PATTERN -mmin N -mtime N -name PATTERN -newer FILE -nouser -nogroup -path PATTERN -perm [-/]MODE -regex PATTERN -readable -writable -executable -wholename PATTERN -size N[bcwkMG] -true -type [bcdpflsD] -uid N -used N -user NAME -xtype [bcdpfls] If I type "man find" on my Mac, I get help for a different version of find, which suggests I can use "-ctime 20w". This does not work in unRAID. Expected behaviourI type "man find" and can get the correct syntax, because unRAID installs the man pages for its commands. Please could unRAID support actually having documentation for its commands? Man pages were working on the old Sun 3/50s that I was using in the late 80s, and they had considerably less CPU and disk space that what any unRAID user is running now. There's room for them! There really is!

Why does checking for port forwarding with PIA take so long sometimes? 2025-09-04 09:34:02,652 DEBG 'start-script' stdout output: [info] Port forwarding is enabled [info] Checking endpoint 'georgia.privacy.network' is port forward enabled... 2025-09-04 09:42:03,692 DEBG 'start-script' stdout output: [warn] Json query '.regions | .[] | select(.port_forward==true) | .dns' returns empty result for port forward enabled servers, skipping endpoint port forward check [info] Script finished to assign incoming port Using the PIA Mac desktop app, I can connect directly to that endpoint in a matter of seconds. This took eight minutes and, even then, the line afterwards looks like it timed out and just assumed there was no port forwarding. Is there a variable I can change to reduce the timeout to something a bit more sensible, like 30 seconds? (And now, after it's printed that line, it's sat there for another four minutes, with no VPN connection and no proxy server — meaning that it's now 16 minutes since I started the container at 09:31 and it still isn't up. It never used to take this long — and, as I said, I can connect from my desktop machine using the PIA app in just a few seconds, so it doesn't seem to be PIA at fault…) Further update: it seems to be something with the Georgia endpoint; startup was back to the usual speeds when I switched to a different country. It's a pain to have to do this, though, as some services require you to tell them if you're using a VPN, and which country you're using, so you have to go and edit your profile in all of them…

After the nextcloud container auto-updated last night, it didn't restart (because the mariadb container hadn't finished restarting). Once I restarted it manually, it sat in maintenance mode for ages, then asked me to create a new admin user, as if it had been freshly installed. The existing admin user and non-admin user are still there; neither of them can edit users, either (which is correct for the non-admin user, but the admin user should be able to do this). If, when logged in as the admin user, I go the Administration Privileges page, I have an option for "Administration Privileges — Users" which I can leave empty or set to Local, but if I set it to Local and then log out and back in again, I still don't see a link to User Management. How can I make my original admin user into a super-admin so that I can get on with administering this instance? (And why did it destroy my setup when updating, anyway? Even restoring from an appdata backup didn't get it working again…) UPDATE: oh, wait. For some reason the config.php is 0 bytes long. Despite my having restored it from a backup 🙄 Fortunately, manually restoring that one file and restarting Nextcloud seems to have done the trick. (It also doesn't help that the Nextcloud documentation titles the section User Management and implies there's a User Management link on the Administration Settings, when in fact it's called Accounts and is on the profile icon at the top right. It's probably not the Done Thing to use the rolling eyes emoji twice in the same paragraph, but…

Thanks — that seems to work when I try accessing the site in a browser that hasn’t accessed it before. In Vivaldi, opening a new tab and accessing the site also works. Simply reloading an existing tab gives this, which caused a bit of confusion! Off to the Vivaldi bug reporter I go…

Is it possible to have wildcard certificates for more than one domain? Annoyingly, wildcards don't cover subdomains, so a wildcard for *.example.com doesn't cover *.subdomain.example.com as well. I guess I could spin up a second container with its own appdata, but that seems rather wasteful