trurl

Current stable is actually 6.8.3. That uname response is just telling you the linux kernel version, not the Unraid version. Are you booting from a USB2 port? You should.

That one will be a serious bottleneck for parity checks or rebuilds since all disks are sharing a single eSATA port (and you don't even want to consider using it from the USB port). How large are your current disks? Simplest solution to get more capacity might be to just upsize your disks starting with parity.

Don't hesitate to ask for advice. The number one reason for screwing things up is doing something without asking.

Why are you using the command line to mount it instead of Unassigned Devices? Will windows do checkdisk on it?

You shouldn't have 2 "routers". One of these needs to be configured as an access point. You should only have a single DHCP server on your network.

Assuming you are accessing the webUI from a browser on another computer, then you just use the print capability of that browser.

I recommend not sharing disks on the network. If you need to work with the disks do so directly on the server with mc (Midnight Commander) or krusader or command line. In any case, don't mix disks and user shares when moving / copying or you can lose data. Just one of several reason I recommend not sharing disks.

Since the bug is reported and still open in 6.9 and 6.8 isn't likely to be patched then I agree with johnnie.

Your VMs can have vdisks on the array, or they can access Unraid shares on its virtual network.

You can go directly to the correct support thread for any of your containers by clicking on its icon and selecting Support.

You control whether and how each user share uses cache. The default for appdata, domains, system shares is cache-prefer, which means try to keep them on cache if there is room. This will give better performance for dockers/VMs since they won't be impacted by parity updates, and so they won't keep array disks spinning. The default for all other user shares is cache-no, which means don't write to cache.. Changing a user share to cache-yes will write new files to cache then move them to the array according to the mover schedule.

You could use the NVME as cache and not use the SSD. That will be plenty for both dockers/VMs and general caching. I don't recommend trying to combine the NVME and SSD into the same pool, mostly because they aren't the same size, but also because the SSD is probably slower.

Is everything using DHCP?

Why do you have multiple subnets?

First we need to figure out what is on disk1 in the system share. You really want all of that share on cache but diagnostics is showing some of it on disk1. Do you know how to examine the disks? Do you have any VMs?

Actually this is the first time the word "formatted" has appeared in the thread. That word always worries me when I see a user mention it. How exactly did you do this "format" and why?

The latest beta has multiple pools for SSDs, etc. You could use the NVME as fast storage for dockers/VMs and use the SSD in a separate pool for normal caching. That is basically what I do except I have 256GB NVME as fast storage and 2x500GB SSD as cache. You won't get all that speed with parity.

I'm thinking what may have happened is you had the root of user shares /mnt/user as the destination for restoring appdata, with the result that they were all replaced with only the restored appdata.

Perhaps you really meant to say "cache disk" instead of "flash disk". There is no "flash appdata". And you really don't want any data on flash. Flash is just the archive of the OS, and settings from the webUI. The OS archive is unpacked fresh into RAM at each boot, and the OS runs in RAM. Saved settings from the webUI are loaded into RAM, and updates to these settings are saved to flash so they can be reapplied at boot. These are normally the only way flash is used, and you don't want to even attempt to save anything to flash yourself, and flash shouldn't get a lot of read/writes so it will last. appdata is a user share. That user share, along with system and domains user shares, are used by your dockers/VMs, and it is best if these user shares are kept on cache so dockers/VMs performance will not be impacted by slower parity updates, and so these won't keep array disks spinning. Your user shares are on cache and array, and have nothing to do with flash beyond the settings for each user share which you make in the webUI. User shares are simply the aggregated top level folders on cache and array. In addition to a backup plan (make one now), another lesson you might consider is asking for advice before doing the wrong thing.

Maybe he means his internet service only provides 100mbps. Combining NICs won't help with that.

But there is almost no data on his disks. Flash backup will not help with that.

Instead of a photo of the Dashboard, what you want is a printout of Main. That will show all the disk assignments with their serial numbers. Only the serial number assigned to a slot is important, doesn't matter which port it is plugged into.

Have you done memtest?

Post your diagnostics

Unrelated to your issue, except as it relates to the difficulty of making sense of your syslog. Your syslog goes back a few days, I guess this is when you booted back up after So whatever happened we don't have any record of. And many things don't show up in syslog anyway, such as User error of some kind seems the most likely explanation. A little unclear about this part. Appdata Backup makes a backup of appdata, and it can make a backup of flash. The "appdata settings", the way I would interpret that, is the settings for the user share named appdata. Those would be on flash along with a lot of other things, and could be restored from the flash backup if you had that set up. Did you restore the data for the appdata user share? If so, I don't see why this would have been needed, since replacing flash should have no effect on the data on your drives, such as the appdata user share. Or did you restore the flash backup? Or both? Maybe a screenshot of your settings for CA Backup plugin would have a clue what happened, though it won't help now. This is probably your only hope. You must have a backup plan. You absolutely must have another copy of anything important and irreplaceable.