cmr-raid

Why does a new version of 7.1.2 with release date 2025-06-02 exist? The original version of 7.1.2 was released 2025-05-11. I do not believe silently updating releases without any notice or version number bump encourages customer trust. 2025-05-11 MD5 checksum: b2fe221ba16da3e7e77ed21573f598ef 2025-06-02 MD5 checksum: 4e346b06a0752fb9d85358474efc22ba

If any Limetech employees are watching, it should be possible to disable the mover on a schedule when it can corrupt stuff. Moving hundreds of gigabytes of files over SMB between shares seems unreasonable, and I don't think it's an advanced use case to move files with the CLI.

I was moving a ton of files last night between two shares with the mv command in terminal, inside /mnt/user/. While doing this, mover began running automatically. The chance of me having moved a file while mover was moving it, is very high. Is mover safe in regards to this? Running checksum checks on the data will time consuming.

I have the same problem. Just installed the plugin and enabled the Reycle Bin feature, but files deleted over SMB don't go in the recycle bin, they just vanish. This happens both through mapped drives and network drives.

UPDATE! Before deleting the file to give up, I tried copying the file through SMB to another folder, in the same share, by drag-n-drop. The 3G file appeared in the new folder, but now the original 65G file showed up in the original folder I dragged it from! No corruption as far as I can tell with the backup software. I have no idea what wild bug this is, but it definitely is something Limetech should look into.

I assure you I didn't mix this up. In the WebUI it had the target path /mnt/user/share2/folder1, and in the terminal I did the 'mv' command with ../share2, so this cannot have crawled out back to /mnt/ .

The share name leak my real life name, I'm not posting that here. This was the exact command with the share names changed. One of the share names do contain a hyphen if that is important. No spaces, if that even is possible.

/mnt/user/share1# mv ./backupfile ../share2/folder1/

Hello. I wanted to move a 75G file from one share to another, and it was a great opportunity to test the new move functionality in the WebUI. To my dismay this was extremely slow. Before I've always used the move command 'mv' in terminal, this has never failed me. Today I noticed I have "some or all files unprotected" on the share that I moved the file to. I can't get rid of this by running the mover, or disabling and then re-enabling cache. I now see, that the file it complains about is the 75G file, except that the file no longer is 75G, but only 3G. My guess is that the file managed to transfer 3G before I aborted it in the WebUI (I got no warning that his could lead to dataloss in any way). Me using the mv command in terminal might have done something, but UnRAID didn't warn me of anything while I tested the move functionality in the WebUI. As far as any normal user would know, the transfer was simply canceled, when I clicked that action in the WebUI. The WebUI tells me, that the file resides on both the cache and array, 3G on each. Terminal with 'ls -lh' confirms the same for me on both the cache and array drive. My cache drive is as empty as it normally is, so I guess the file is actually lost. Either this is a bug, or an undocumented consequence of my steps in moving the file to another share. I do not believe I've done anything a normal user couldn't do, and UnRAID really should warn of what can go wrong, when using the move functionality inside the WebUI. Of course it's simply my guess that aborting the move and then using mv is at fault, if anyone has another idea I welcome them to comment. //The file lost was unfortunately an irreplaceable backup, and as it never got onto the right share, it was never backed up to my second NAS.

Thank you. After taking a closer look I've done everything in ssh_config instead of sshd_config For anyone stumbling over this thread, I uncommented these following lines PasswordAuthentication no PermitEmptyPasswords no KbdInteractiveAuthentication no They're close together in the sshd_config template file you find in /etc/ssh. Copy them to /boot/config/ssh and make your edits there to have them persist across reboots.

How can I disable password authentication for SSH? I can't get anything I've found to work. Putting ssh_config into /boot/config/ssh and modifying it to have "PasswordAuthentication no" uncommented has not worked. Good day to all and thanks for the help.