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.

Snubbers

Members
  • Joined

  • Last visited

  1. Just more upto date instructions for those using this from scratch in 2026 It failed to work on first run with the permissions issue.. I did change the appdata folder permission: chown -R nobody:users ROMVault/I had to delete the DatRoot, RomRoot and ToSort folders from the appdata\RomValue folder as I had these configured to folders on my array but it still created them in appdata.. (new) I had to edit the template, 'show more settings' and set "Take Config Ownership" to 1 Now, I'm in the webui and its scanning my roms..
  2. I’m pretty sure for myself it is something to do with hanging web sockets when accessing services via cloudflare tunnels, as every time I start accessing services via that method, the message starts appearing fairly quickly if I access using Tailscale, it never appears.
  3. I see other threads for this, but don't want to pollute individual support instances unique to an individual.. However, I've noticed recently The WEB UI seems 'laggy'.. a gross measure using Chromes dev tools shows LCP's for 1.5-2.5s most of the time, going between Unraid UI sections (e.g. Settings and Tools) far from snappy. (It's OK in safe mode with the array stopped) Externally, I'm using a cloudflare tunnel (using a cloudflared container) to access internal services, mainly as work (bless) won't allow tailscale (naturally)... but I have (for about 12 months) had the issue that access the server externally has websocket issues with the streaming stuff always hanging, so I can't see CPU usage graphs on the dashboard, or the array information. Now, having moved to entirely new hardware (but retaining all disks), I've noticed that logs do say "php-fpm[9710]: [WARNING] [pool www] server reached max_children setting (50), consider raising it" And sure enough, there are 50 or so php-fpm processes showing in Tools->Processes.. I also have entries saying "monitor_nchan: Stop running nchan processes" Now, I rebooted yesterday as I've still been messing around with the new server so wanted a clean session.. I noted on reboot I only had about 4 or so php_fpm processes.. Today I went shopping and whilst having some breakfast, checked in on things via the cloudflare tunnel.. I also checked in from a friends house about 30 mins ago.. On getting home and checking the logs, I notice the same 50+ php_fpm processes and a couple of nchan stopping entries in the log that do seem to coincide with me accessing the server via the cloudflare tunnel services I am running 30+ containers, many with their own WEB UIs that are super snappy and responsive, and a Home Assistant VM, and everything otherwise is absolutely fine, the processor is largely just ticking over with 1-3% usage shown, and the main array spends most of its time spun down since I have 5 x NVME and 1 x SSD which I pretty much run all the run time stuff from.. When accessing the server externally, by and large the array stays spun down. My gut feeling from other threads is the websockets not working correctly via the cloudflare tunnel may be causing issues and causing the many php-fpm processes, but clearly I could do with someone more knowledgeable to just cast an eye on things and make sure I'm not being daft. I've attached diagnostics... nas-diagnostics-20260207-1221.zip
  4. Just bumping this as I too am running Netdata and had the same warning which was the same Docker vidsk problem. And a balance sorted it out.. I'm confident it was down to me installing around 12 containers in a day and messing around (now all tidied up!), I've double checked all containers and can't find any misconfiguration now and will keep an eye on things. I wonder if it's something that would be useful adding to the Unraid UI? i.e. if BTRFS allocation being that high is a potential sign of an issue, why not inform users?
  5. Same here.. I actually just uninstalled Unraid connect to work around it. What I did notice is that the 'Gray' theme did honour the custom background override, but the 'Black' theme does not.. Going to the developer tools in Chrome, you can see in the Black theme the hierachy of background colour is ignoring the custom one and pulling in the default.. Also, trying to reinstall and then signing in just has it hanging with the modal signing in dialog spinning forever..
  6. I have a cloudflared tunnel (docker) on a VLAN br0.60 to allow external access to various services. Immediately on upgrading to 7.2.0 I noticed that whilst the tunnel shows as connected to cloudflare (via their Zero trust admin panel), some services where just not accessible (just sat there spinning in chrome until they give a timeout error (cloudflare message).. On investigating, I've found the tunnel works fine for Directly to the Unraid NAS itself Other devices on the local network (e.g. NVR device) some vlan'd containers (on br0.40) Containers on 'host' network What it doesn't seem to work for are Containers on custom networks Containers set to 'Bridge' I have popped a thread in the respective sub forum for the container, but its not that well frequented and I suspect it might be some nuance with 7.2.0 and custom networks.. The cloudflared tunnel logs show this for services not responding: 2025-11-05T08:40:14Z ERR error="Incoming request ended abruptly: context canceled" connIndex=3 event=1 ingressRule=2 originService=http://192.168.71.2:7878 2025-11-05T08:40:14Z ERR Request failed error="Incoming request ended abruptly: context canceled" connIndex=3 dest=https://xxxx.xxxxxxxx.co.uk/ event=0 ip=198.41.200.13 type=http I haven't tried rolling back yet, because if it's a small issue that can be worked around, I'll hang in there! nas-diagnostics-20251105-0826.zip
  7. Anyone else having issues post 7.2.0? My cloudflared isn't working for connecting to many local services and the logs show lots of the following: "025-11-04T19:34:58Z ERR Request failed error="Incoming request ended abruptly: context canceled" connIndex=3 dest=https://xxxxx.xxxxxxxxxx.xx/ event=0 ip=198.41.192.47 type=http" My network setup is a little convoluted. I can access all the services locally from my PC, so all are running and fine, just any attempt by the tunnel to access a service ends with the above errors. @Figro My cloudflared container is in a vlan br0.60 Seems to be containers in custom networks, those that can be set to 'host' are working fine, and so are those in other vlans (e.g. br0.40) and I can access the unraid NAS itself via the tunnel.. Weird..
  8. The issue is simply the config directory default is not pointing at the correct app data folder, and then it doesn't have the correct permissions. To fix it: Edit the n8n container, change the Config directory to "/mnt/user/appdata/n8n" and apply that change. Stop the container. From an Unraid terminal run the following: chown -R 1000:1000 /mnt/user/appdata/n8n Start the container. That should do it! If you get the 'SSL' error when loading the webpage, you need to add a new variable to the template, N8N_SECURE_COOKIE with the value of FALSE
  9. Slightly convoluted, but effectively I did a 71.2 - > 7.1.3 upgrade and had issues with connectivity (no web ui accessible from the local network), so rolled back to 7.1.2 (using USB creator tool) and whilst I had connectivity back to the web UI, had issues with dockers Logs showed the container couldn't find the network ID All br0.x VLANs where missing in the drop down list when editing a container and 'docker network list' showed they indeed did not exist. I removed and re-added all VLANs, keeping the same Docker settings for those (IP ranges, DHCP Pools etc) This still didn't work I then found posts on here about the 'non standard' CIDR for DHCP address pools on VLANs, and I was using x.x.x.224/28 which is a valid CIDR subnet, but just set that to x.x.x.0/28 anyway, restarted everything and all the br0.x vlans reappeared.. I reset each container to the corresponding vlan br0 and all containers started fine. I then noticed that my old docker config had vlans defined such as 192.168.0.1/24, but now, in both 7.1.2 and 7.1.3 I can only select CIDR subnet masks of 25-30.. Anyway, with it largely 'working', I re-upgraded to 7.1.3 on the basis I thought it might have been my CIDR DHCP pools on the vlans.. And on reboot to 7.1.3, even though the docker/vm manager is not enabled, just starting the array causes connectivity issues ifconfig shows br0 is up with the correct static IP. eth0 is also present and shows no issues wget {server ip} from the command line will get index.html, so that's working The array is up (disks are mounted and can browse the shared folders from the command line) I've attached pre array start and post array start diagnostics files if that helps in anyway.. I might have to revert back to 7.1.2 again, the only oddity is those VLAN subnet masks being limited to 25-30 and obviously I'd like to get to the bottom of this as my install is a few years old now, so might have some unwanted baggage that needs sorting out. nas-diagnostics-20250606-1034.zip nas-diagnostics-20250606-1030.zip
  10. So there are the two aspects, Firstly, setting the BIOS up.. look at the first post of the other thread: Check your BIOS, you definitely need to disabled the TOS Boot option.. Effectively You need to get to a point you can select the first boot device as your UEFI USB Stick, or your BIOS/USB Stick will never boot. Once at that stage, confirm its all working by hitting F12 at boot which brings up the manual boot selection screen, and selecting your UEFI USB Stick, it should boot.. The problem is at each reboot, the BIOS will hang (black screen or just stuck) when it tries to boot from the USB automatically.. So the final step and workaround for this is the modify the \syslinux\syslinux.cfg file on the USB stick just adding the line "default Unraid OS" as the first line, so syslinux.cfg should now start: default Unraid OS menu title Lime Technology, Inc. prompt 0 timeout 50 This worked for the rest of us with F4-424Max and F6-424 Max units..
  11. I did turn on ASPM if it was an option, but that only covers 3 x PCIe buses, and the net effect was only allowing the NVME drives to reach L1: Here's the ASPM status: lspci -vv | awk '/ASPM/{print $0}' RS= | grep --color -P '(^[a-z0-9:.]+|ASPM )' 00:06.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 (rev 04) (prog-if 00 [Normal decode]) LnkCap: Port #5, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <16us LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ 00:06.2 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #2 (rev 04) (prog-if 00 [Normal decode]) LnkCap: Port #5, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <16us LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ 00:1c.0 PCI bridge: Intel Corporation Device 51bc (rev 01) (prog-if 00 [Normal decode]) LnkCap: Port #5, Speed 8GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ 00:1d.0 PCI bridge: Intel Corporation Device 51b2 (rev 01) (prog-if 00 [Normal decode]) LnkCap: Port #11, Speed 8GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal] (prog-if 02 [NVM Express]) LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ 02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal] (prog-if 02 [NVM Express]) LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ 03:00.0 Ethernet controller: Aquantia Corp. AQC113C NBase-T/IEEE 802.3an Ethernet Controller [Marvell Scalable mGig] (rev 03) LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ 04:00.0 SATA controller: ASMedia Technology Inc. ASM1166 Serial ATA Controller (rev 02) (prog-if 01 [AHCI 1.0]) LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ The NVME drives I had are power hungry Samsung 990pro's, but they do support ASPM nicely, so the power saving from those is over 10W alone.. I also generally turn off the 'turbo' mode for the CPU, it doesn't make a difference to the idle power consumption, but it does stop it getting close to 90C if running a full iGPU/CPU immich machine learning session which maxes out the entire CPU.. it will hover around 70C-75C if I turn off turbo
  12. Using the following in a script running after the array starts, I've had zero errors in the logs now with some pretty extensive use of the NAS, and idle power with 5 x 14TB 7200RPM drives + 2 NVME Samsung 990 Pros + 1 Crucial MX500 4TB is 21W, and hourly average with all dockers/vms running is 25w the majority of the time, but during scheduled backups and other media duties (downloading etc). It averages 30W over a day.. Prior to the power tweaks, it was almost double that.. I've not upgraded or checked the ASM firmware at this point, I could easily boot to windows using an external USB HDD and do an upgrade, but at this point 30W average over 24hours with nearly 20 containers running and a VM is about as good as I need. # Enable SATA link power management echo med_power_with_dipm | tee /sys/class/scsi_host/host*/link_power_management_policy # Runtime PM for I2C Adapter (i915 gmbus dpb) echo auto | tee /sys/bus/i2c/devices/i2c-*/device/power/control # Autosuspend for USB device echo auto | tee /sys/bus/usb/devices/*/power/control # Runtime PM for disk echo auto | tee /sys/block/sd*/device/power/control # Runtime PM for PCI devices echo auto | tee /sys/bus/pci/devices/????:??:??.?/power/control # Runtime PM for ATA devices echo auto | tee /sys/bus/pci/devices/????:??:??.?/ata*/power/control
  13. Just bumping this as the white header was annoying me somewhat (as a 'dark mode' user!), so good to see a way to sort this. I do wonder if this could not be morphed to a proper dark/light mode? Or at least tweak the (much appreciated!) themes to have the '333333'/'FFFFFF' pre-set.. This forum gets it right btw, a nice dark/light mode toggle and good palette choice for dark mode. Very minor, but that kind of polish is always appreciated!
  14. I've been on a server upgrade (or side grade) journey for a week or so. Part of that was moving from 6 array data disks of various sizes (4/8/14TB) + 4 SSDs to 4 x 14TB data disks + 1 SSD.. This has meant juggling many TBs of data from smaller disks to larger disks, then shrinking the array, rebuild parity and now moving more data.. The one thing that bugged me is the HDDs will do 230->135MB/s for the parity rebuild, but moving data disk-disk I get ~60MB/s in normal write mode and ~70MB/s in Turbo Write (all using default settings). However, tonight, moving another 5TB (many ~10GB files) of data around I just start reading the Help on the tips and tweaks plugin page and see that the dirty_background_ratio and dirty_ratio values are default (10/20) and it mentions using smaller dirty_background_ratio values for some workloads (gaming?) and give it a go.. and Bam.. 100MB/s+ sustained disk to disk in Turbo Write mode and much less HDD 'thrashing' I've done 2TBs now without issue.. (Just tweaking a bit and 3%/10% for the two dirty ratios seems to be around 105MB/s sustained.) I see a few people struggling with the lower 60-70MB/s speeds in reconstruct write mode and just thought I'd throw it out there and see if what I am doing is not a good idea, or if it is just down to experimentation?
  15. I've also tried running the syslinux.exe to recreate the MBR with the slow option, and also the raid option with no luck. It could be the bootx64.efi is the issue, its clearly running something as the screen goes black, or in some cases the BIOS splash (Need to disable 'quiet mode' in the BIOS to see the splash screen) just hangs, it if didn't detect any bootable entity/try to execute something it would go directly in to the BIOS if that was the only boot option which it doesn't. I've also experimented with the TOS Boot option, basically replacing the internal USB with an Unraid USB drive, then enabled the TOS Boot does nothing.. The TOS Boot USB is not a normal UEFI Fat32 architecture either.

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.