trurl

This issue is far less common than the SQLite problem. Or at least far less reported and not reported for some time. It's possible some users just let their servers carry on with a few parity errors not knowing any better.

In fact you shouldn't even attempt to use a server with memory errors. Try reseating the modules and repeat memtest.

The new Unraid can read and write the data from your old Unraid. But it is recommended to convert from ReiserFS to another filesystem. XFS is usual for the array, and btrfs is required for cache pool of more than a single disk. Converting to another filesystem sounds easier than it is. You basically have to reformat, so you will have to copy the data elsewhere. You can do this one disk at a time though, since ReiserFS disks can still be used in V6 and mixed in with XFS disks etc.

There have been a number of reports with VM Manager problems on 6.8. See here: https://forums.unraid.net/bug-reports/stable-releases/cannot-disable-vm-r801/

I think the unclean shutdown parity check is always non-correcting regardless of that box. So you will have to complete a correcting parity check to get the parity errors fixed. In any case, it seems an unclean shutdown is at the root of the complaint. And link to the FAQ already posted.

Were you actually getting an error message, or were you just getting the login prompt? I run headless also. It always gives a login prompt at the console, and logging into the console is not required to use the webUI. And it looks like you did successfully login to the console. Did you read the link I gave on how to get us more information?

You wouldn't find it in /boot. The flash drive only contains the archive of the OS, and settings from the webUI. That archive is unpacked into RAM at each boot. Try this instead: which mover

The only acceptable number of memory errors is exactly zero. Everything ultimately goes through RAM, your data, the executable code, everything.

You have it basically correct regarding /mnt/user0 as of the date of that post you quoted, but as itimpi noted I don't think the current version of Mover uses /mnt/user0 at all.

Just a bit of advice on using the forum. If you put new information in an old post it can often be overlooked. In this particular case, since you mentioned it I knew to look for it. And since you had in fact made a new post then the thread showed as unread. If you had only edited an old post without making a new post it's possible I would have never visited the thread again. I seldom look at syslogs for this old version. I did use V5 back then but didn't try to help out much, and I may not remember some things about it. One of the improvements in V6 that make it a better NAS, even if you don't intend to use any of the other features, is better diagnostics and notifications. The last thing in your syslog is about unmenu restarting a couple of times. I don't know but that doesn't seem normal. Jan 3 04:43:18 Tower unmenu-status: Exiting unmenu web-server, exit status code = 141 Jan 3 04:43:18 Tower unmenu-status: Starting unmenu web-server Jan 3 04:43:24 Tower unmenu-status: Exiting unmenu web-server, exit status code = 141 Jan 3 04:43:24 Tower unmenu-status: Starting unmenu web-server Have you tried it without unmenu? I think you can just comment it out of your go file. Have you done memtest?

I usually recommend fewer larger disks instead of more smaller disks, and wouldn't consider buying anything as small as 2TB these days, but since you already have them, if the drives have good SMART reports then use them. But I am even less clear on the idea that you don't have RAID but you have "mirrored" drives". Unraid doesn't mirror anything, except in the special case of a single data disk with a parity disk. If those 4 disks you say you have don't appear as 4 individual disks then that is not a recommended configuration. Do you have a parity disk?

Why not just use the WireGuard VPN builtin to Unraid V6.8?

No Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

1 parity 1 data is a special case which results in a mirror. I think that might perform somewhat better with parity updates than the more general case of multiple data disks but I haven't tried it. Once you get more than 1 data disk it doesn't matter how many you have it works the same assuming no controller bottlenecks, since the disks are accessed in parallel. See this for more information on the 2 methods of configuring parity updates and their tradeoffs:

The important thing to remember is that files on cache and files on the array are both files in user shares. If you want a copy of something in both cache and array then they need to be separate shares, or at least paths sufficiently different so you don't get a collision. For example /mnt/cache/share1/file1 and /mnt/disk1/share1/file1 are both seen as file1 in the share1 user share.

I'm a little unclear on your disk assignments. Unraid is NOT RAID and RAID isn't recommended for Unraid, it just complicates troubleshooting and other things. Perhaps most importantly for your immediate situation, it's going to complicate getting their data transferred to a new build if you can't get the older server going again. Doesn't sound like there is much to salvage except perhaps the data. Probably a whole lot easier to just get the data from your backups to transfer to the new build. I think your budget is unrealistic. It might be possible to reuse the disks but I don't really even recommend that.

If those were the sensors that were working on your old hardware then I wouldn't expect them to be the same on your new hardware. Did you

Here is the thread this was posted in originally: https://forums.unraid.net/topic/79454-file-transfer-results-in-error-0x8007003b I split it into this other recent thread of yours so we could deal with it separately from the other users issues, and because it isn't clear that you don't have multiple related problems. Your approach to fixing these issues doesn't make much sense, to me at least. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

What exactly do you mean by "stopped" here? The usual meaning would be using the Stop button on Main - Array Operation. And "started" would usually mean using the Start button on that page. But according to your syslog, the parity check for unclean shutdown happens right after booting up. Jan 1 12:09:30 Extraodinary kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot ,,, Jan 1 12:10:25 Extraodinary emhttpd: unclean shutdown detected ... Jan 1 12:10:43 Extraodinary kernel: mdcmd (47): check nocorrect Jan 1 12:10:43 Extraodinary kernel: md: recovery thread: check P ... ... Jan 1 13:27:44 Extraodinary kernel: md: recovery thread: P incorrect, sector=1574961048 Jan 1 13:27:44 Extraodinary kernel: md: recovery thread: P incorrect, sector=1574961056 Jan 1 13:27:44 Extraodinary kernel: md: recovery thread: P incorrect, sector=1574961064 Jan 1 13:27:44 Extraodinary kernel: md: recovery thread: P incorrect, sector=1574961072 Jan 1 13:27:44 Extraodinary kernel: md: recovery thread: P incorrect, sector=1574961080 ... Jan 2 17:44:46 Extraodinary kernel: md: sync done. time=106443sec Jan 2 17:44:46 Extraodinary kernel: md: recovery thread: exit status: 0 This was a non-correcting parity check and it detected parity errors, so you need to run a correcting parity check to get those corrected. The only acceptable number of parity errors is exactly zero. So when you said "stopped" did you actually mean you powered your server off with the power button instead of using the webUI to shutdown?

There are 2 ways you can get into trouble with the paths a docker application uses. If you have an application set to write to a path that isn't part of a mapped container volume, then those writes will go into the docker image. Typical mistakes are not using an absolute path (beginning with /), or using different upper/lower case than specified in the mapping (linux is case-sensitive). If you have a mapping which specifies a host path that isn't mounted storage, then writes to the corresponding container path will be in RAM, since the Unraid OS is in RAM. Note that a host path that specifies an Unassigned Device that isn't mounted is in RAM.

Split into its own thread so we can keep things straight

Split into its own thread so we can keep things straight

I recommend not sharing drives on the network. There a few different ways you can get yourself in trouble with that.