gubbgnutten

I assume your "below setup" is referring to your signature? For someone who has not explicitly enabled signature viewing, it sure looks like you forgot to add something to your post

Especially at the command prompt! But yes, to stay safe - stick to user share to user share and/or disk to disk and never mix user and disk. Sure, but it is not part of "/mnt/user/domains archive" so it is not triggered by this transfer. Still best to point out the risk of mixing user shares/disk shares anyway, of course.

If a file is present in /mnt/cache/media, it will also be present in /mnt/user/media. That does not mean that it will still be there if you delete it from the cache disk. /mnt/user is the combined contents of the array's data disks and the cache disk/pool. /mnt/user0 is the combined contents of the array's data disks only. Hopefully you tried to move files to the latter... In any case, try to figure out how the files ended up on the cache disk in the first place. My bet is on either a misconfigured plugin/docker container or that they were saved to a share using the cache and then moved to media using mc or similar.

Do you use plugins/docker containers to download/process media files? If so, check their configurations. If you deleted the media folder from the cache drive without moving the files it contained first, you probably lost them... The setting "no" only relates to writing, not to reading. If files are present on the cache drive folder corresponding to the "media" share, they will show up in the regular "media" share even if it is set not to use cache drive.

Because they are in /mnt/cache they will show up in /mnt/user as well.

Maybe old board links could be redirected as well? For example, https://lime-technology.com/forum/index.php?board=71.0 redirects me to https://forums.lime-technology.com/?board=71.0 rather than https://forums.lime-technology.com/forum/55-general-support/ Looking forward to checking out the new forum more thoroughly later

And exactly how much space is Explorer telling you is available on the Movies share?

Updated diagnostics to reflect the current situation would be great. 700GB free is not really interesting, we need to know the free space of the individual drives contributing to the 700. Which share are you copying the file to? Where do you actually see the error? What's the exact wording? Do you get the error immediately or halfway through the transfer? Is the "over 140GB" a single file? BTW, you should set the minimum free space to a value larger than the largest file you are going to write to the user share. unRAID does not know how large a new file will be. With minimum free set too low, it can try to write to a disk with too little space free.

Exactly! The colors are not originally present in the log, they are added by the GUI. That is why there are false positives (and possibly uncolored real problems), the GUI uses some basic rules to try to guess whether a row mentions a problem or not. Whenever I add supposedly static data to my server, I also add a file containing the checksum of each added file. I would for example have added the file "Necro - 2004 - The Pre-Fix For Death.md5" in the folder "Necro - 2004 - The Pre-Fix For Death" (I think TeraCopy can do that for you, actually). Then I can later verify that the files in that folder have not changed by running md5sum -c "Necro - 2004 - The Pre-Fix For Death.md5"

Well, unDERP is obviously not happy at all with your taste in music... On a more serious note, the color highlighting in the log viewer is far from perfect. I would assume that the moved filenames are just falsely triggering the heuristics.

Rebuilding will not fix filesystem corruption.

Since the file starts with "._", I would assume that you have the real key in the file Plus.key, and that the USB drive was at some time plugged in to, or accessed by, a Mac. The ._filename contains the resource fork for the filename file. In your case, the following most likely apply: Plus.key - Real key. ._Plus.key - Resource fork, not a valid key, only used by Mac. Maybe unRAID should ignore ._*.key files?

You're welcome! I'm sure your memory modules will enjoy the hammer tests Never really know what memory test result to hope for when there is an obscure problem present...

The mover is moving a bunch of bait files from the cache to the array. Not a user of the ransomware plugin, so I don't know if that would trigger anything. There is also an update available.

...and please do interpret "If you can, run the later version" as "Run version 7 unless it is completely impossible".

The JBOD confusion has been going on for quite some time. Probably because many motherboards and RAID add-in cards used just "JBOD" to denote a JBOD spanned volume, saving a few precious characters... Reminds me of another lazy hack that we are still suffering for, 2^10.

No, you're not experiencing the same, "missing csrf_token" and "wrong csrf_token" are completely different things. You probably have a web browser active somewhere with a stale web ui. Close or reload it/them.

As far as I know non-ECC RAM works with G7.

Welcome! 35MB/s with gigabit and SSD cache sounds way too slow (when transferring a large file and not a load of tiny ones). The diagnostics zip would answer many questions about your setup and help rule out some common pitfalls. A wired read test would be nice as well. As for wi-fi, what speeds do you get for SMB between your laptops over wifi/wifi to ethernet?

Yes, officially it maxes out at 8GiB, but 16GiB actually works great for lots of people on the HP G7 MicroServers. Got a N54L myself with 16GiB. They are a bit picky when it comes to 8GiB modules, though. If 16GiB is tempting, search the web for failure/success stories for the combination of N36L and specific memory modules. KVR1333D3E9SK2/16G might be worth checking out.

No, you don't need a parity disk. In your situation with 2xSSD I would probably go for two data disks and no cache.

I would try the support thread for that docker.

Can you still access the web UI when this happens, or the console/SSH/Telnet? If so, grab diagnostics after the problem occurs, but before rebooting. See Need help? Read me first! for instructions.

Removing them from the flash drive should work better. /etc/ssh only exists in RAM and is populated with files from the flash drive during startup.

It was actually powering down in such a way that I had to shut the psu off so that I could turn it back on. Im in the process of moving files off one of the resierfs disks so that I can convert it to xfs. Really? Sure sounds like a dodgy PSU to me.