echocabinet

1 week later: [03.02.2026 05:31:20][][unifi-controller-reborn] Starting unifi-controller-reborn... (try #1) done! [03.02.2026 05:31:23][][Main] Backing up the flash drive. [03.02.2026 05:32:35][debug][Main] flash backup returned: tower-v7.2.3-flash-backup-20260203-0531.zip [03.02.2026 05:32:39][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 32702464 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191 [03.02.2026 05:32:40][][Main] Copying flash backup to destination failed![03.02.2026 05:32:40][][Main] Checking retention... [03.02.2026 05:32:40][debug][Main] toKeep after slicing: root@tower:~# free -h total used free shared buff/cache available Mem: 15Gi 10Gi 597Mi 3.3Gi 7.6Gi 4.6Gi Swap: 0B 0B 0B root@tower:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 7.8G 3.2G 4.7G 41% / devtmpfs 7.8G 0 7.8G 0% /dev Still having this issue and not sure of the root cause. The appdata backup appears to have saved correctly otherwise. Manual flash backup is: 1.2GB In the backup location today, it did attempt to save the flash, but it is corrupted at 480.8MiB.

16GB RAM. # free -h total used free shared buff/cache available Mem: 15Gi 11Gi 490Mi 2.1Gi 6.5Gi 4.5Gi Swap: 0B 0B 0B # df -h Filesystem Size Used Avail Use% Mounted on rootfs 7.8G 2.0G 5.8G 26% /

[27.01.2026 05:32:08][][Main] Backing up the flash drive. [27.01.2026 05:33:19][debug][Main] flash backup returned: tower-v7.2.3-flash-backup-20260127-0532.zip [27.01.2026 05:35:02][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 18874368 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191 [27.01.2026 05:35:02][][Main] Copying flash backup to destination failed! When I manually backed up the flashdrive, the size was about 1.6GB. It has backed up previously with similar sizes.

Observed a strange error today during the scheduled backup. I looked through the thread and didnt see anything similar right off the bat. [27.01.2026 05:35:02][debug][Main] PHP-ERROR occured! 8 / copy(): Write of 18874368 bytes failed with errno=28 No space left on device /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php:191 Both my flashdrive and destination have an excess of 10GB, so I am not sure exactly which space it is talking about. root@tower:/tmp/appdata.backup# df -h /usr/local/emhttp/ Filesystem Size Used Avail Use% Mounted on overlay 7.8G 2.0G 5.8G 26% /usrAny ideas? Thanks!

@adoucette fwiw, I ordered two Swissbit drives at the same time. Each drive has a unique serial number printed on the outer drive body, but that number does not match what win11 has for the SerialNumber value using: Get-CimInstance -ClassName Win32_Volume | Where-Object { $_.DriveLetter -eq "F:" } | Format-List * For Unraid, the GUID appears to match the class ID_SERIAL_SHORT from: udevadm info --query=all --name=/dev/sda | grep ID_SERIAL This value partially matched my unraid key registration, in the "Flash Vendor ID + Product ID + Serial Number" format. See: https://forums.unraid.net/topic/675-argh-how-to-get-flash-guid-from-windows For clarification, the ID_SERIAL_SHORT value did not match the printed Swissbit Serial Number on the outside of the device. Comparing the two drives, the ID_SERIAL_SHORT values are different, but only by 2 digits of the 16 digit value. I hope it is unique enough.

I got this working with the swissbit SFU34096E1AE1TO-C-MS-1B1-STD. Unfortunately the unraid media creation tool did not recognize the usb flash GUID, so I had to build it manually. Luckily the license key transferred successfully with the swissbit guid. This worked. I used this process to get it booting from UEFI: https://forums.unraid.net/topic/117868-solved-trouble-getting-started-cant-boot-to-unraid-usb/#findComment-1079115 This process did NOT work: Rufus fat32 with the no-boot option, then running the make-bootable.bat (after copying the manual install unraid files to the flashdrive) did not work.

Another thought. This blacklist without an appeals process becomes a bit risky from a cost perspective, with an expensive drive.

I randomly had my Kingston DataTraveler Kyson 32GB USB 3.2 drive get blacklisted yesterday or the day before. I have been using it for: 2024.10.27 - installed 295 days can be converted to one of these units: 25,488,000 seconds 424,800 minutes 7080 hours 295 days 42 weeks and 1 day 80.82% of a common year (365 days) So this being a yearly thing is getting annoying enough that I am going to try the swissbit industrial SLC drive. https://www.mouser.com/c/embedded-solutions/memory-data-storage/storage/usb-flash-drives/?memory%20size=4%20GB&instock=y If I have trouble using it, my backup will be a Samsung BAR Plus 64GB USB 3.1, but I will have to work around the larger size. Smaller drives are impossible to find locally, so this makes locating compatible drives a big problem. Even Amazon is left with off brands or 3rd parties selling smaller drives. It seems like all of the smaller Samsung drives are off the market from official channels.

It was working fine, but then I went from some version to 2024.10.27 and now I have the blank Dashboard. * Found the support thread:

With Tunarr intel build, I am unable to add the plex server. It authenticates and i can see it listed on the plex side, but it never shows up or completes. Tried it with Brave and Edge. Any ideas or is there a way to add it manually?

I am still running 6.12.4, and prior to today my uptime was over 2 months, but unfortunately i have been working with the unraid server webpage open and forgot about checking logs. The system locked up within 5 hours and i had to hard reboot. Are people still seeing this issue on 6.12.6? *** NOTE: My uptime was only that stable because I change the server webpage tab to unraid.net when I am not actively using the web console.

The bug report for this issue is in this thread: 6.12.4 - Gets unresponsive (Have to Cut power & hard reboot) - Stable Releases - Unraid Luckily it has been reopened. Hopefully it will get some visibility.

After another week, I have determined a few things: Closing all tabs prevents the errors from building up/cascading. The browser type doesnt seem to matter. Crashes/logs growing happens with Edge, Chrome, and Firefox. My appdata backup (which runs on Monday mornings) has been one of the triggers for the nginx errors in the logs. When the tab is open, the log fills up with the errors while the scheduled job is running. I do not blame the plugin, because when the tab (all tabs) are closed, the errors are not generated. Closing the tab today prevented a hard crash like last week, which required a hard shutdown. This is a webserver based interface. If the primary mechanism for accessing the OS causes the OS to consistently crash, then it is a bug.

This is still happening about once every 12 hours, but it alternates between the nginx logs being full and just the syslog being full. Just blindly nuking them at this point. I am using Edge and noticed it is getting faster since the last update. No evidence for that though, just an observation. Still willing to help get this resolved.

@martial try stopping and then starting the service, instead of restarting. That kept me from needing to reboot previously.