trurl

All New Config does is reset your disk assignments. Nothing else is changed.

Sounds like you have nothing to worry about. Building parity will simply calculate parity by reading all other disks and write the result to the parity disk. Since parity is calculated last in your scenario, it will be in sync with all other disks. Clearing disks is only about keeping existing parity when you add a disk to a new slot. A clear disk is all zeros and so doesn't change the parity calculation.

You will always get a parity check if it can't record a clean shutdown. Let it complete just in case.

My guess is a coding error overwrote the OS folders. Hopefully it didn't get to /boot or /mnt yet. Reboot and make sure you don't run that script again.

Any disk assigned as parity will get overwritten with parity, simple as that.

So memtest failed?

Why? You might be able to delete old logs (syslog.1, syslog.2, ...) in /var/log. Doubt you can delete the current syslog.

Tools - New Config

I have split the posts you made about this same problem in other threads all into this thread. Please don't post about the same problem in multiple places. It makes it impossible to coordinate responses. Crossposting has been considered a bad thing on message boards since before the World Wide Web.

Probably anything entered at the command line would be reset on reboot since the OS is in RAM.

Rebuild of disk1 already completed when diagnostics were taken Sep 10 09:13:36 ur1-meppel kernel: md: recovery thread: recon D1 ... ... Sep 10 14:04:45 ur1-meppel kernel: md: sync done. time=17469sec Sep 10 14:04:45 ur1-meppel kernel: md: recovery thread: exit status: 0 And you are having connection issues on cache Sep 10 09:09:17 ur1-meppel kernel: ata1.00: ATA-10: KINGSTON SA400S37120G, 50026B77834CF063, SBFKB1E2, max UDMA/133 ... Sep 10 09:25:12 ur1-meppel kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Sep 10 09:25:12 ur1-meppel kernel: ata1.00: failed command: FLUSH CACHE Sep 10 09:25:12 ur1-meppel kernel: ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 30 Sep 10 09:25:12 ur1-meppel kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Sep 10 09:25:12 ur1-meppel kernel: ata1.00: status: { DRDY } Sep 10 09:25:12 ur1-meppel kernel: ata1: hard resetting link Don't know anything about Proxmox. Are you referring here to Unraid User Shares? User Share names are anonymized in Diagnostics (take a look for yourself to see what I mean). You have a number of shares all beginning with p and ending with s, and there are share .cfg files 2 shares that don't exist, one beginning in p and ending in s, and another beginning in c and ending in r. Looks like most of your disks are empty or nearly so. Did you format any of them recently, perhaps because they were unmountable?

Try renaming config/network.cfg on flash then reboot to get back to default network settings

That is the painless part. Previous Apps on the Apps page will reinstall all your dockers exactly as they were. If you do nuke docker.img, you will have to recreate any custom docker network you had. If you were following Spaceinvader video to setup letsencrypt then you did.

I thought you meant you had added another pool, which is what I was suggesting. It looks like instead you added another disk of a different size to existing cache pool. Default is btrfs raid1, which gives a mirror with total capacity only equal to the smaller disk. So, that cache pool only has 240G. And, a pool is all one storage volume, so there is no way to separate out different things onto different drives, such as appdata, etc. Also, your appdata and system still have files on the array, and your parity is invalid.

Diagnostics would give us a clearer and more complete idea how you have reconfigured.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

This is a different thing from VPN into your network. You need a VPN service, typically you would pay for that. Your internet traffic is routed encrypted and anonymously through the VPN service.

I do this with the WireGuard VPN built-in to Unraid since 6.8

Your appdata and system shares still have files on the array. They can't be moved while they are open so you have to go to Settings - Docker and disable before trying to move them.

I thought perhaps looking back in syslog to boot would reveal if you had unclean shutdown, but unfortunately boot time is not in the syslogs in diagnostics because your syslog is being spammed with these: Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [0E59246677B6\064Attic\032SB\032Touch._raop._tcp.local#011IN#011SRV 0 0 40781 bigboi-2.local ; ttl=120] not fitting in legacy unicast packet, dropping. Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [bigboi-2.local#011IN#011A 192.168.0.3 ; ttl=120] not fitting in legacy unicast packet, dropping. Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [ABA7EBC51E26\064Kitchen\032SB\032Touch._raop._tcp.local#011IN#011TXT "42351" "tp=UDP" "sm=false" "sv=false" "ek=1" "et=0,1" "md=0,1,2" "cn=0,1" "ch=2" "ss=16" "sr=44100" "pw=false" "vn=3" "txtvers=1" "am=shairtunes2" ; ttl=4500] not fitting in legacy un Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [ABA7EBC51E26\064Kitchen\032SB\032Touch._raop._tcp.local#011IN#011SRV 0 0 42351 bigboi-2.local ; ttl=120] not fitting in legacy unicast packet, dropping. Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [_afpovertcp._tcp.local#011IN#011PTR bigboi-2-AFP._afpovertcp._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping. Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [bigboi-2-AFP._afpovertcp._tcp.local#011IN#011TXT ; ttl=4500] not fitting in legacy unicast packet, dropping. Sep 9 22:21:57 bigboi avahi-daemon[4724]: Record [bigboi-2-AFP._afpovertcp._tcp.local#011IN#011SRV 0 0 548 bigboi-2.local ; ttl=120] not fitting in legacy unicast packet, dropping. Any idea what that's about? It would make it difficult to figure out any other problems you might have.

This question makes me wonder if you understand how cache works on Unraid. When writing to a cache-yes user share, parity is not involved. The write will happen at the speed of cache. Later, at the scheduled mover time, those files get moved to the parity array. At that point, parity is involved, but that is independent and long after the write to cache. Parity is realtime, cache is not. Mover is intended for idle time. The default mover schedule is daily in the middle of the night.

After reboot syslog resets, but syslog is only one of many useful things in diagnostics. And even syslog after reboot will have anything that is currently happening. It just won't have anything that happened before reboot. So

Even if you did have parity, I have to ask. Do you have another copy of anything important and irreplaceable?

It will see the new drives, and since they are not the drives it is expecting, you will have to New Config / Trust Parity. Be very sure you don't assign a data disk to any parity slot.