February 26, 20251 yr 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.
February 26, 20251 yr Author 10 minutes ago, trurl said: What exactly was your 'mv' command? /mnt/user/share1# mv ./backupfile ../share2/folder1/ Edited February 26, 20251 yr by cmr-raid Made comment more concise.
February 26, 20251 yr Community Expert Do you really have user shares named share1 and share2? Or is that not really the exact command?
February 26, 20251 yr Author 5 minutes ago, trurl said: Do you really have user shares named share1 and share2? Or is that not really the exact command? 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.
February 26, 20251 yr Community Expert Just make sure you don't mix user shares and disks/pools when moving or copying.
February 26, 20251 yr Author 2 minutes ago, trurl said: Just make sure you don't mix user shares and disks/pools when moving or copying. 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/ .
February 28, 20251 yr Author 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.
March 1, 20251 yr Community Expert Can you consistently reproduce this? If yes, post the details of how to.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.