Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

ElectricBadger

Members
  • Joined

  • Last visited

Everything posted by ElectricBadger

  1. I am getting this problem as well — it sits a "checking issues" for an unacceptably long time, with no indication that it will ever complete. Would it be possible for the issue checker to output a percentage progress, just so users know whether they should hang around waiting for it or come back tomorrow?
  2. I had to upgrade the base OS Pihole that provides DHCP, and now it will not resolve my unRAID server in DNS because the unRAID server has not asked for a new DHCP lease. Forcing unRAID to renew its DHCP lease proved to be more difficult than I'd hoped. It would be great for there to be a "renew DHCP lease" button next to each interface in Settings > Network Settings, but there is not. Online tutorials say to use `dhclient`, but it's not installed. Eventually I realised that you could do it with killall -HUP dhcpcd so I wanted to leave this here in case anybody else is having trouble (but also to ask for a Renew Lease button in the UI )
  3. If an error is made in the Extra Parameters setting when configuring a Docker container, the container is not added to the list of containers. If an error is made when editing this setting for an existing container, the container is removed from the list of installed containers and the user configuration is lost. There is no warning or confirmation before this happens. To reproduce: Install the GitLab CE container and start it. Edit the container settings. Add the following to Extra Parameters: --env GITLAB_OMNIBUS_CONFIG="external_url 'https://git.example.com';nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n proxy_cache off; \n proxy_pass http://plantuml:8080/; \n}\n";prometheus_monitoring['enable']=false;" Note that the code pasted from https://docs.gitlab.com/ee/administration/integration/plantuml.html uses double quotes which should have been escaped, as it's already inside double quotes. An easy error to miss, but one with a hefty penalty, as it causes the container creation to fail. This causes the container to vanish; when reinstalled, any existing configuration changes are lost and the container has its default settings once more. Expected behaviour: the container remains installed, in a stopped state, with its existing config. The user is free to edit that config until they come up with one that works. I'm marking this as Urgent as it is, technically, a data loss bug (while I didn't lose any data from the container's volumes, I did have to recreate all the config options. If I didn't have a copy of that Extra Parameters, which I've pasted a sanitised version of below, it would have taken hours to get the container up and running again.) --env GITLAB_OMNIBUS_CONFIG="external_url 'https://git.example.com';registry_external_url 'https://registry.example.com';gitlab_rails['usage_ping_enabled']=false;gitlab_rails['lfs_enabled']=true;gitlab_rails['gitlab_ssh_host']='git.example.com';gitlab_rails['gitlab_email_from']='[email protected]';gitlab_rails['smtp_enable']=true;gitlab_rails['smtp_address']='mail.example.com';gitlab_rails['smtp_port']=25;gitlab_rails['smtp_authentication']=false;gitlab_rails['smtp_tls']=false;gitlab_rails['smtp_openssl_verify_mode']='none';gitlab_rails['smtp_enable_starttls_auto']=false;gitlab_rails['smtp_ssl']=false;gitlab_rails['smtp_force_ssl']=false;gitlab_rails['manage_backup_path']=false;gitlab_rails['backup_path']='/backups';gitlab_rails['backup_archive_permissions']=0644;gitlab_rails['backup_pg_schema']='public';gitlab_rails['backup_keep_time']=604800;nginx['listen_port']=9080;nginx['listen_https']=false;nginx['hsts_max_age']=0;nginx['client_max_body_size']='0';nginx['custom_gitlab_server_config']='location /-/plantuml/ {\nproxy_cache off;proxy_pass http://plantuml:14480/;\n}\n';registry_nginx['listen_port']=9381;registry_nginx['listen_https']=false;registry_nginx['client_max_body_size']='0';registry_nginx['enable']=true;registry['enable']=true;gitlab_rails['pipeline_schedule_worker_cron'] = '7,37 * * * *';prometheus_monitoring['enable']=false;postgresql['auto_restart_on_version_change']=false" celestia-diagnostics-20220801-0905.zip
  4. If I stop the array and then restart it, all Docker containers that have autostart set to ON are restarted. The same does not apply to VMs: they only autostart after a full reboot, and must be restarted manually in this case. This is really annoying, as I usually forget to do this and don't notice until I try to use something that's running on a VM and find it's not working. Would it be possible for autostart to be consistent between Docker and VMs, and for both to autostart things after an array stop/start? celestia-diagnostics-20220219-1402.zip
  5. Yes, the plugin autoupdates, so it's current. Looks like Firefox doesn't support the `list` attribute for `input type='color'`, so not a lot you can do here. I'll use Vivaldi for when I need to edit colours. Thanks!
  6. Everything I'm reading suggests that I should get a dropdown when I click on a custom colour control, which includes an option to reset the colour to its default. However, in Firefox on macOS, I just get the standard system colour picker. The posts I read were from a while ago — has the behaviour changed since then? There no longer seems to be a way to reset a colour to default without resetting them all to default…
  7. I am using binhex-delugevpn, and occasionally the endpoint goes down, requiring the container to be restarted. If, while the container is restarting, I click on its icon and choose Logs, the logs open, but the container is left stopped. Once this happens, attempts to stop the container produce "Execution error — container already started", even though `docker ps` shows that it is not. Turning the entire Docker service off and on again does not clear this and allow Unraid to get back in sync — only a full reboot (which takes about 5–10 minutes with a Dell R720) will clear things. Is there a way to force the frontend to throw away what it thinks the Docker state is, and set it based on `docker ps`? And are there any plans to allow the frontend to multitask properly, so that users can restart a container and then bring its logs up without having to wait for the restart to complete? (This also occurs to an extent when starting multiple containers — if you click Start on one, then click Start on a second before the first has finished starting, it gets confused, though not usually to the point of requiring a full reboot…) (EDIT: Actually, in this particular case, it looks like the container wasn't starting anyway, because I'd messed up a config file, so that may not have helped. But I have had Unraid get out of sync before when doing this. It's possible that restarting the whole Docker service might have avoided the reboot if I hadn't messed up the config files, though!)
  8. Please could we have the RSS feed? It shouldn't be too difficult to implement, and it makes life much easier for those of us who do use RSS. I get far too much email as it is, and I don't want to know about new videos and popular forum posts — just blog articles. IMHO, without an RSS feed, it shouldn't even be called a "blog"
  9. When I run the Docker container, the log says XML template file for the vm was placed in Unraid system files. This file assumes your vm path is /mnt/user/domains if it isnt you will need to manually edit the template changing the locations accordingly Would it be possible for it to output the path to that XML file at that point, instead of just saying "Unraid system files"? I've looked all through /boot and I can't find it — and I need to change /mnt/user/domains to /mnt/disks/vms… EDIT: d'oh — I can just edit the XML after restarting the server and before starting the VM, of course. Might be more helpful if the message mentioned that, for the decaffeinated 😁
  10. Do we need to change anything in our unRAID configs in order to continue getting updates to this container, if it's being renamed? Or will the rename get picked up automatically?
  11. Ah — I was connecting to port 7806 with the VNC client. That explains a lot. I don't have Chrome installed, but Vivaldi is based on Chromium (it loses a bunch of Google-specific stuff I don't want, and adds several very useful configuration options). As I said, it worked fine there, too. I cleared the Firefox cache and it still didn't work without using private mode — but clearing all cookies and localStorage set by the unRAID machine did. Not sure what had got stored that was causing the confusion, but it's all resolved now. Thanks for your help!
  12. It works inside a private window, and if I use Vivaldi rather than Firefox Developer Edition (but that's a pain as I have to copy/paste the link rather than just clicking, obviously). All adblockers are disabled for the unRAID server's address in Firefox, but not in Vivaldi — but they all report nothing is blocked, anyway. I've tried disabling each extension individually, with no effect. Most of them were active in Vivaldi anyway. The connection doesn't get established when I use TigerVNC. console.log.txt It's very mysterious… ¿ⓧ_ⓧﮌ
  13. Thanks — no joy with a cache clear, or with enabling privileged mode. Doesn't work in Vivaldi or Firefox (where it used to work). This is what I get in the browser console: Msg: Starting VNC handshake util.js:218:50 Msg: Sent ProtocolVersion: 003.008 util.js:218:50 Source map error: Error: request failed with status 404 Resource URL: http://192.168.69.99:7806/css/bootstrap.min.css?v=be005ac911 Source Map URL: bootstrap.min.css.map WebSocket on-close event util.js:218:50 Msg: Server disconnected (code: 1006) Not sure the source map error is relevant and it sometimes occurs after the server disconnect.
  14. I can't get the Web UI to work — I just get the toolbar at the top with a red X next to the MakeMKV logo. When I mouse over the X, I see a tooltip with the message "Server disconnected (code: 1006)". I've tried uninstalling and reinstalling the container. There is a "s6-svwait: fatal: timed out" in the log (attached) but I don't know if it's significant. Does anybody have any idea what's going wrong? I've just bought a new DVD box set that I'd like to rip… log.txt
  15. I've been having a similar problem — I'm using a Dell R720 with a NIC that has four ports, but eth0 and eth1 are SFP fibre ports. I'm using eth3, but unRAID lost the DNS config once I switched. The network settings page has the DNS settings under eth0 rather than either per-port or separate from all the ports. unRAID had decided to bridge eth3 to eth0, even though I'm not using eth0. When I turned bridging off on eth0, and enabled it on eth3 with no other interfaces on the bridge (and then had to change the bridge on every VM — a "bulk edit" mode would be greatly appreciated) DNS stopped working after a reboot. When I looked at /boot/config/network.cfg, these lines were missing: DHCP_KEEPRESOLV="yes" DNS_SERVER1="192.168.1.1" DNS_SERVER2="1.1.1.1" DHCP6_KEEPRESOLV="no" Adding them back in and rebooting seemed to confuse unRAID, because console now said this after boot. Presumably the code that generates this is assuming eth0 will always be used. unRAID Server OS version: 6.8.3 IPv4 address: not set IPv6 address: not set I could still ssh in, but the web interface was down. I eventually resolved this by reverting to the original network.cfg that used eth0 for everything, and editing /boot/config/network-rules.cfg to change the port assignments, so the port in use is now treated as eth0. (That might be an easier fix for anybody else who has a port failure )
  16. Thanks — I've opened a second ticket as they seem to be ignoring my first. Wonder if PayPal will authorise a refund this far along?
  17. Since yesterday morning, my PureVPN connection has been unable to connect. It looks like both of these options are now removed from /root/openvpn.sh — I've tried various combinations of these three options: --pull-filter ignore 'dhcp-option DNS6' --pull-filter ignore 'redirect-gateway sipv6' --pull-filter ignore 'dhcp-option DNS' but none seems to work. I've attached the log and the latest .ovpn file that I'm using. I downloaded that from PureVPN today, in case the certificates were out of date, but I get the same results. I'm assuming that file is right, but given how their website really makes you search for help if you're daring to not use their GUI, who knows? Does anyone have any idea what could be going wrong here? It would be lovely to be rich enough to throw away the remaining 2.5 years on this PureVPN subscription and just pay PIA's rather higher prices, but it's not really an option, unfortunately… sweden.ovpn vpn.log
  18. Rats, I thought I was on the Deluge thread here. Sorry!
  19. After stopping and starting the array, VMs set to autostart are not started, while Docker containers marked as autostart are. Reproduction steps: Install two Docker containers: letsencrypt and emby. Set the letsencrypt container to autostart, but leave autostart disabled on the emby container. Start both containers manually if they are not already started. Create two VMs called a and b. Set a to autostart, but leave autostart disabled on b. Start both VMs manually if they are not already started. Go to Main and stop the array. Start the array. Go to Docker and verify the state of the containers. Go to VMs and verify the state of the VMs. Expected behaviour: The letsencrypt container and the a VM are started. The emby container and the b VM are stopped. Actual behaviour: The letsencrypt container is started. The emby container is stopped, as are both VMs — the autostart setting has been ignored for VMs. (In case it shows in the diagnostics: I had already restarted one VM manually when I remembered I needed to grab diagnostics :) celestia-diagnostics-20200625-0918.zip
  20. It is not possible to add a user with the username "mail". (Presumably this is because there is already a system-created account with this name in /etc/passwd). However, when clicking "Add", the unRAID logo animates as normal, then appears to complete with no error message. It's only after clicking "Done" that you realise the user was not created. This means going back and creating the user with a different name, but having to retype password and description, and re-upload the image. Is it possible to have unRAID display a message when the username already exists? Ideally, it would show on blur of the username field, but on clicking "Add" would probably do, as long as the field values are preserved. celestia-diagnostics-20200620-1051.zip
  21. I have a VM configured that was using the Ubuntu template, and which I decided to install Debian on. Once I had installed Debian, I was unable to change the icon using forms mode — the "Update" button changed to "Updating…", both that and the "Cancel" button were greyed, and no progress appeared to be made. On reloading the page after one minute, the icon was still Ubuntu and both buttons were re-enabled. I was able to make the change by changing the line <vmtemplate xmlns="unraid" name="Ubuntu" icon="ubuntu.png" os="ubuntu"/> to <vmtemplate xmlns="unraid" name="Debian" icon="debian.png" os="debian"/> in the XML, but I assume the GUI is meant to be able to update this or why would it let me choose an icon when I click on the existing one? 😀 One point to note is that this VM had previously been edited in XML mode. Reproduction instructions: Create a new VM of type Ubuntu. Install a version of Ubuntu (20.04 should be fine on it). Decide to install Debian instead. Stop the VM. Change the attached image to a Debian installer. Start the VM. Realise that the boot order will need changing as it has ignored the image. Stop the VM. Swap the boot order of the disks in XML mode as form mode doesn't support doing this (but that's a separate feature request…) Start the VM. Install Debian. Stop the VM. Swap the boot order back in XML mode. Change back to forms mode. Try to change the icon using forms mode. Wait. Wait some mode. Continue waiting. After more than a minute, reload the page. Observe that the change has not been made. Edit the VM in XML mode and make the swap above. Return to forms mode, and observe that the change has now been made. This was only that easy because I still had an Ubuntu VM to copy from, otherwise I would have to have guessed at the correct line or created a new VM just to be able to copy a line from the XML. (Aside: is there really no way to enter monospaced text in a post?) celestia-diagnostics-20200604-1137.zip
  22. Is it possible to have an expand/collapse control on both the "Ignored Errors & Warnings" section, and the "All Ignored Errors & Warnings" sections? Currently, if a problem is found but it's not something you need to fix (not having Unassigned Devices + installed when you don't need its features, say), ignoring it takes you from one item in FCP's page to two, meaning it's more visually intrusive to set it to ignored! If each section started collapsed, and there was an "expand" button (preferably in something a little more subtle than that shade of orange ) then it would make the page a lot less cluttered — currently it's hard to see where new errors stop and ignored errors start as the ignored errors still seem to scream "look at me!"
  23. The letsencrypt proxy only handles HTTPS, not SSH — I think I posted that to show what I was doing to get HTTPS working, but it's been a while since I did that Forwarding the port should be all you need to do for SSH, but I decided not to bother with SSH in the end, and just use HTTPS. I can't offer much more help at the moment as my container doesn't seem to want to come up after the last auto-update…
  24. My container won't come up after updating, either. I don't see that message — but it's difficult to select things from the log, or even read it, when GitLab outputs so much to the thing. I wish the log viewer had a pause button, or at least didn't keep jumping to the bottom every time there was new output… Update: I don't know what it was doing, but the container came back up by itself after being down for just under 24 hours. Some particularly meaty database migration, perhaps?
  25. The "registry" is because I'm using GitLab's Docker registry rather than pushing to DockerHub (from when my upstream connection was only 0.5Mbps). Port 9381 is to put registry.mydomain on a separate port from git.mydomain so the nginx proxy can redirect accordingly. It's safe to skip both those bits if you don't need your own Docker registry.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.