Videodr0me

Just wanted to provide the info for the 6510T - and yes for this hacky solution i had to modify the fan control script. I did not yet had the time to test the new driver on that asustor model. If it works, its naturally a better solution than these tricks.

For just fan control you do not really need this, you can just force a similar enough it87 module. On the 6510T I found modprobe -r it87 modprobe it87 force_id=0x8628 fix_pwm_polarity=1 to work quite well (you also need the lax option enabled). On my previous 5110T just modprobe it87 fix_pwm_polarity=1 sufficed. But i its of course much neater to have a proper asustor it87 module, I will try loading it via modprobe and see if it works on the 6510T later. Just as you i always wanted to get around controlling the LEDs and the LCD display, and also found the mentioned repos, but i also never got around to actually doing something with it. If anybody has already done so (regardless of asustor model) any code snipped to change the LCD text would be much appreciated.

How do i use this? I installed it on a Asustor6510T running unraid 6.12.8 and rebootet. Nothing really changed - all LEDs are still always on. Do i need to do something to control the LEDs?

When updating from 6.12.6 to 6.12.8 one of my dockers no longer started (SFTPGo). Turned out that one of the ports (50057) was already in use by a process: rpc.mountd. This process (AFAIK) is mainly responsible for NFS discovery. I had turned NFS support on, but no shares where exported NFS. In previous versions rpc.mountd used port 10499 (the port might be randomly assigned, but previously never in the 50000 range.- at least not on my servers). I turned NFS completely off and the docker started normally. So if you get an error like : Docker: Error response from daemon: driver failed programming external connectivity on endpoint SFTPGo (ee1aca2871bbdc630466f81d8b7a7c24ec39c91afec730ba61a050efc8cb4850): Error starting userland proxy: listen tcp6 [::]:50057: bind: address already in use. keep this in mind.

Reboot restored functionality. Still this is a very annoying bug.

Changed Status to Open Changed Priority to Urgent

root@Tower-II:~# fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: Samsung SSD 970 EVO Plus 2TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 2048 3907029167 3907027120 1.8T 83 Linux

I completely forgot to follow up on my post. Two Years later, i can confirm that it did fix the issue completely for me. So setting: global-share-settings->tunable(enable hard links) to no solves the issue and the oppo now displays all entries.

Thanks for answering. I also noted that the UI flashed "starting array" repeatedly in the status line, even though the array was already running and accessable from other machines. I guess not being able to read from the boot flash device confused the ui completely. If rebooting is fine, i figured a shutdown would be even better, as i might alvage some of the flash data. I proceeded like this: 1) I shutdown the machine, which was only partly successfull. Telnet, network and all other services seemed to have stopped but the machine was still running after 15 minutes. So i did a hard power off. 2) I put the USB-Stick in a windows machine, it said it had errors. I was still able to access all files and made a backup. 3) Then i used the windows check and repair function which ironically finished by stating no errors found. I used the safe remove feature and unplugged the stick. 4) i plugged it back in again to check if windows would still find errors. It did not. Then i checked some of the files against a backup and everything seemed fine. 5) I plugged the stick back into the Unraid server (same usb port as its the only one) and turned the machine on. 6) Everything seems normal, except for the unsafe shutdown and a parity check which is running now. 7) The plugins i tried to update when the whole incident startet seemed to not have written anything to the boot device, both plugins had the update available again through the normal update check. I updated both without any problems. So the problem seems solved, but it might only be a matter of time before the usb stick fails again. I will try to get a new one in the next days and transfer everything to the new stick. Is there anything i should know/do in advance to make the license transfer as smooth as possible. Also i think that unraid should be made a little bit more resilient and graceful if a flash device error occurs. For example if the error message flash device error is displayed why does it still try to access the boot device from numerous pages of the webui? Also it should probably not try to start the array constantly in such cases (or at least not display the message in the status line). And finally a shutdown should still be possible. I know its probably a rare failure - my first of this kind in years with two servers - but everything that makes unraid more robust is welcome.

One of my servers that has been running for years (6.9.2) suddenly shows "flash device error" in the upper right corner. It happened after i installed an update to community applications. During the update the log showed an error that it could not create a directory. Then the message in the upper right corner appeared. Also on the dashboard page there a a couple of error messages way down that indicate that a couple of cfg files (probably from the flash device) can no longer be read. I guess the flash drive went bad. So how do i proceed from here? Is there a way to backup the currently running config or should i go back to a previous backup? How do i transfer the licence to a new usb drive? Or might it me just a fluke and is it safe to reboot the system and retry?

Got it! Everything is clear now! Thanks for patiently explaining this.

Thanks very much for explaining. I think i understand the issue better now but one question remains. If the uuid is identical how does unraid know which drive to include in the array? Lets say I have the new drive inside the array (the old drive is removed from the server) and everything is already rebuilt: If i now shutdown the server, connect the old drive (now both drives are connected), power on and start the array - how does unraid know which of the two drives to include in the array? Or does it remember the drives not only by uuid but other info as well?

Thanks for the info. I am still unsure exactly when I need to change the UUID. Do i have to do it before i remove the drive, or do i change the UUID before mounting it with unassigned devices for the first time? Is there a reason why i have to change the uuid? I thought that when i set the drive to "not assigned" (step1) and start the array (step 2) unraid will forget that this uuid belongs to the array. Is this assumption wrong?