Vexz

The 1GB RAM limitations have been removed and of course after the reboot eveything is back to normal again. But will it stay that way? I think only time will tell. nas-diagnostics-20260611-1600.zip

Greetings. I woke up today and saw that my unRAID server suddenly has about 86% RAM usage, which is very unusual. I've been using unRAID for almost 1,5 years now and never had this happen, so I was surprised to see this. Usually the RAM usage is about 42%. So I asked the AI and it told me to execute a "free -h", which displays 16 Gi in the "buff/cache" column. It said everything is fine and it just means that my RAM is used efficiently. But we all know you can't blindly trust AI and I've never had this happen before, so I'm very skeptical. Would love to know what's actually happening here. Diagnostics attached. Thanks in advance. nas-diagnostics-20260611-0808.zip

Ich weiß nicht, ob es dafür (bereits) eine offizielle Lösung gibt, ich konnte zumindest keine finden, aber es ist zumindest eine, die man einfach, schnell und sicher durchführen könnte. Vielleicht wird es noch irgendwann eine extra Option dafür geben, unRAID von einer SSD auf eine Andere zu migrieren.

Freut mich, dass du es hingekriegt hast. Für das nächste Mal, sollte etwas schief gehen, mach am besten immer ein Backup von deinem unRAID System, damit du nicht nochmal alles neu installieren und konfigurieren musst. Im Grunde reicht es auch schon den Pfad /boot/config zu sichern. Da ist alles drin, um mit dem Unraid USB Flash Creator Tool dein unRAID wieder genau so wiederherstellen zu können, wie es vorher war.

Ist möglicherweise nicht die schönste Lösung, aber du könntest einen USB Stick in deinen Server einstecken, das unRAID System auf diesen migrieren und dann von da aus auf die Optane SSD.

You probably missed my edit of the OP, right at the top. I fixed it and everything is working fine now.

Update I fixed it with a restore of a backup on a new USB device and deleted all partitions via console on the SSD first. I just upgraded to 7.3.1 and installed an SSD before doing so to migrate the system to the SSD after the update. While going through the process I encountered this error: ➜ Starting configuration... ➜ Starting internal boot setup. This might take a while... ➜ Configuring internal boot pool... ✗ Internal boot setup returned an error: assignableDisks snapshot: [{"id":"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T","serialNum":"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T","device":"/dev/nvme0n1"}] assignableDisks resolved serialNum->device: [["Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T",{"bootId":"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T","devicePath":"/dev/nvme0n1"}]] Running: emcmd debug=cmdCreatePool,cmdAssignDisk,cmdMakeBootable Running: emcmd cmdCreatePool=apply&poolName=boot&poolSlots=1 mkbootpool: command failed or timed out emcmd request failed with status 500 Technical details { "request": { "operation": "CreateInternalBootPool", "variables": { "poolName": "boot", "devices": [ "Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T" ], "bootSizeMiB": 0, "updateBios": true, "reboot": false } }, "response": { "ok": false, "code": 1, "output": "assignableDisks snapshot: [{\"id\":\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",\"serialNum\":\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",\"device\":\"/dev/nvme0n1\"}]\nassignableDisks resolved serialNum->device: [[\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",{\"bootId\":\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",\"devicePath\":\"/dev/nvme0n1\"}]]\nRunning: emcmd debug=cmdCreatePool,cmdAssignDisk,cmdMakeBootable\nRunning: emcmd cmdCreatePool=apply&poolName=boot&poolSlots=1\nmkbootpool: command ...[truncated]" }, "status": 1, "error": { "name": "Error", "code": 1, "message": "Internal boot setup returned ok=false", "category": "unknown", "networkError": { "status": 1, "result": { "ok": false, "code": 1, "output": "assignableDisks snapshot: [{\"id\":\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",\"serialNum\":\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",\"device\":\"/dev/nvme0n1\"}]\nassignableDisks resolved serialNum->device: [[\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",{\"bootId\":\"Samsung_SSD_970_EVO_Plus_500GB_S4EVNJ0N234529T\",\"devicePath\":\"/dev/nvme0n1\"}]]\nRunning: emcmd debug=cmdCreatePool,cmdAssignDisk,cmdMakeBootable\nRunning: emcmd cmdCreatePool=apply&poolName=boot&poolSlots=1\nmkbootpool: command ...[truncated]" } } } } ➜ Updating Server Identity to NAS... ✓ Server Identity updated. ➜ Finalizing setup...I didn't reboot yet, I think the system will not be able to start if I do it. Help is appreciated.

Just upgraded from 7.1.3 to 7.2.0. Everything is working. Thank you!

So safe to ignore, if you don't run VMs inside unRAID?

@tobasium @SvensenDE @nicx Update! I just tested this (using unRAID 7.0.0) and found out that you do NOT need that part with the "/etc/rc.conf". I never created that file and it didn't exist for me, ergo I never wrote something inside that file. The part with the "/etc/rc.conf" was completely skipped. So after you install the microcode with un-get, check the contents of your flash drive in "/boot". Depending on what file you see there (the "intel-ucode.cpio" OR the "intel-ucode.img") you just need to change the part in the Syslinux Configuration in the web UI. In my case the Syslinux Configuration looks like this, because it downloaded the "intel-ucode.img": kernel /bzimage append initrd=/intel-ucode.img,/bzroot After that, just reboot your unRAID server and the microcode update will be applied. Result after the reboot: root@NAS:~# dmesg | grep microcode [ 0.000000] microcode: updated early: 0xe -> 0x1c, date = 2024-09-06 [ 1.975603] microcode: Microcode Update Driver: v2.2. Before the reboot "dmesg | grep microcode" wouldn't give me any output, so there definitely is a change and the patch was applied.

I know now how to find out and it was much easier than I thought after reading the original post again. In the third line of the "/etc/rc.conf" you point to the specific file. So before you reboot, you just check the contents of your unRAID USB drive. I can see the "intel-ucode.img" there, so I know I'd need to use this, not the CPIO-file.

@SvensenDE Then how did you know you needed to enter "intel-ucode.img"? How did you get to know about this file? I mean you must have found out about this somehow and the system must store this file somewhere.

Is there a way to find out which of the two it installed BEFORE you reboot? I'd rather not run into that issue. Would be a big hassle to solve this, because my unRAID NAS is not connected to a monitor (since there is no monitor in that room) and the USB drive is plugged in a USB port directly on the motherboard and cannot be removed, unless I remove the motherboard first.

@etsi @anhvo Works for me on unRAID 7. I downloaded the ITE IT87 Driver, then installed the Dynamix Auto Fan Control. Dynamix Auto Fan Control is a little confusing, but I managed to get it to work somehow. Set "PWM controller" to "it8613 - pwm3". Set "Fan control function" to "Enabled". Now click on the "DETECT" button next to "PWM fan". It might take a while and you might need to click on it twice. It sets the following value: "/sys/devices/platform/it87.2624/hwmon/hwmon2/fan3_input". "Minimum PWM value" is a little confusing. I set it to "100", which results in 1245 rpm. The value "120" gives me about 1457 rpm. You might wanna play around with the values here. Set low and high temperatures to your liking. I chose 35°C for low and 40°C for high. I think you should set the "Refresh interval (minutes)" value to "1", but that's just what I like. Save. Don't be confused if it says "Disabled" for "Fan control function" after saving. It does that, because it shows you the settings for the "it8613 - pwm2" fan controller now. You want that one to be disabled. In fact, you only want "it8613 - pwm3" to be enabled. Choose the "it8613 - pwm3" from the list and you will see that "Fan control function" will say "Enabled". The setting "Fan control function" doesn't enable or disable the fan control function in general - it just sets it for the PWM controller you selected from the list in "PWM controller". I don't know why the devs did this, because it's just confusing. Thanks for this thread. Two of my drives were constantly at 45°C. Now they are at 37°C.

I don't know where to check that, but it must have been my misinterpretation. It was my guess of what happens there, since it took so long. Just ignore it. Thank you very much for your help.

Yes, I specifically said "move", not "copy" in my original post. But when you say that should still not happen, even with datasets, then the problem must be somewhere with ZFS on my unRAID server, right? Edit: If you can trust people on reddit, it's a copy from one dataset to another. So yes, that has to be the issue here. https://www.reddit.com/r/zfs/comments/fvjmmb/is_moving_files_between_datasets_a_copy_operation/

Looks like this is the issue here. I just created a new share (which automatically creates a new dataset), called "Test". In that dataset, I created two new datasets "Test1" and "Test2". I copied a file (around 4.5GB) to Test/Test1. From there I moved it to Test/Test2. It took about 20 seconds to move the file. Just to make sure, I moved the file back to Test/Test1 and then to Test/. It always took the same amount of time. Then I created a folder (not a dataset) Test/Testfolder and moved the file from Test/ to Test/Testfolder and it was instantly there. Conclusion: Moving files from dataset to dataset makes unRAID have to copy the file over to the destination and then delete the source. It's not just a change of the pointer to the file in the file system. @JorgeB can you confirm that?

Yes, a Windows 11 Pro machine. Just tested, but same issue. No issues when I move files to another path on the same share though. Even testet it with a 51GB file. I don't know why it isn't working, but an ugly workaround would be to create just one share, create folders or ZFS datasets in that share with the current share's names and put all the files in these folders/datasets. Wait a minute. ZFS creates individual datasets for each share. Could that be the reason why it isn't working? Moving files from one dataset to another dataset?

Here you go. Samba version 4.21.1 PID Username Group Machine Protocol Version Encryption Signing ---------------------------------------------------------------------------------------------------------------------------------------- 1484851 alex users 2003:c3:ef0a:fe00:fc0b:e5f7:44c6:ddad (ipv6:2003:c3:ef0a:fe00:fc0b:e5f7:44c6:ddad:52228) SMB3_11 - partial(AES-128-CMAC) 1487255 alex users 2003:c3:ef0a:fe00:e809:fa59:c990:3bbc (ipv6:2003:c3:ef0a:fe00:e809:fa59:c990:3bbc:59091) SMB3_11 - partial(AES-128-GMAC) Service pid Machine Connected at Encryption Signing --------------------------------------------------------------------------------------------- Downloads 1487255 2003:c3:ef0a:fe00:e809:fa59:c990:3bbc Sun Jan 26 11:46:08 AM 2025 CET - - Programme 1484851 2003:c3:ef0a:fe00:fc0b:e5f7:44c6:ddad Sun Jan 26 10:29:48 AM 2025 CET - - Docker 1484851 2003:c3:ef0a:fe00:fc0b:e5f7:44c6:ddad Sun Jan 26 10:55:03 AM 2025 CET - - Spiele 1487255 2003:c3:ef0a:fe00:e809:fa59:c990:3bbc Sun Jan 26 11:46:08 AM 2025 CET - - Sonstiges 1487255 2003:c3:ef0a:fe00:e809:fa59:c990:3bbc Sun Jan 26 11:24:12 AM 2025 CET - - Downloads 1484851 2003:c3:ef0a:fe00:fc0b:e5f7:44c6:ddad Sun Jan 26 11:56:32 AM 2025 CET - - Locked files: Pid User(ID) DenyMode Access R/W Oplock SharePath Name Time -------------------------------------------------------------------------------------------------- 1487255 99 DENY_NONE 0x100081 RDONLY NONE /mnt/user/Sonstiges . Sun Jan 26 11:24:12 2025 1487255 99 DENY_NONE 0x80 RDONLY NONE /mnt/user/Downloads . Sun Jan 26 11:46:08 2025 1484851 99 DENY_ALL 0x100080 RDONLY NONE /mnt/user/Downloads . Sun Jan 26 11:56:31 2025 1484851 99 DENY_NONE 0x100080 RDONLY NONE /mnt/user/Docker . Sun Jan 26 12:00:26 2025 1484851 99 DENY_NONE 0x100081 RDONLY NONE /mnt/user/Docker . Sun Jan 26 11:59:49 2025 1484851 99 DENY_NONE 0x100081 RDONLY NONE /mnt/user/Docker . Sun Jan 26 11:52:47 2025 1487255 99 DENY_NONE 0x80 RDONLY NONE /mnt/user/Spiele . Sun Jan 26 11:46:08 2025

I think that was it. Just stopping the Docker containers isn't enough, the Docker service itself needs to be stopped as well. Would be nice if stopping the Docker service was a part of the process when stopping the Array.

So I removed the UD plugin and removed everything from the SMB Extras, but still no luck. Moving a large file from one share to another is still not made server-side. I uploaded a new diagnostics file. nas-diagnostics-20250125-1540.zip

Yes, that's the first half of their statement, which is why I specifically asked for the changes I gave an example for. The second half of their statement referred to the UD plugin. But I can't find a "root share" option in its settings.

Can I instead do individual configurations for all of my shares, where the "path" is set to the shares' path? I really need this SMB configuration. For example: [Downloads] path = /mnt/user/Downloads ... [Backups] path = /mnt/user/Backups ... Edit: Can't find something like a "root share" option in Unassigned Devices. But I can remove the plugin itself. I don't need it that much.

Had to do a little research to know what you mean by "root share hack", as I'm still pretty new to unRAID. I guess it means that "/mnt/user" is accessible via SMB, right? It isn't. Neither do I see it when I check "\\NAS", nor is it hidden, because \\NAS\user" isn't accessible from Windows Explorer. From what I remember, I never changed anything specific to "/mnt/user" directly, just its subfolders. Adding shares from the web UI adds the subfolders in "/mnt/user". To make it short: I use the shares directly (e. g. "/mnt/user/Downloads" is accessed directly via SMB). I guess I have to put that in Main -> Boot Device -> Flash -> Syslinux Configuration -> Unraid OS, right? It looks like this now: kernel /bzimage append initrd=/bzroot mitigations=off pcie_aspm=off Needs a reboot though, which I'm not willing to do right now, as I'm running some tasks on my unRAID server, which take a while to finish first.

I did in the OP, but it looks like it already got removed. Hopefully it won't get removed so fast this time. I moved files from "/mnt/user/Downloads" to "/mnt/user/Spiele". But from what I can tell, it doesn't make a difference from which to which share I move files. nas-diagnostics-20250125-1149.zip