Ruato

One question. I am currently on version 10.0.162. Will my backup file work with version 10.1.185? Or should the new container first be set to the same version as I am currently and updated to the version 10.1.185 only after I have restored from backup?

I was prepared to make the change to Unifi OS but I am happy to continue to utilize the network control docker image. After all, I do not need the extra features the Unifi OS provides: https://share.google/aimode/f7uGhX0CjsU26rPJg. So, thank for continuing to provide support for this!

👍 Did you follow some certain instructions for this?

Same. Everything went smoothly. Thank you @PeteAsking !

It has been years without any major problem. Now, with a scheduled parity check I got 13563 errors. The reason might an incident where the server crashed because it run out of memory (a docker container was the culprit). I checked that the array disks are not reporting any errors. What should I do next? Run another parity check without correcting to check that the report is valid or run a parity check with parity drive correcting enabled? Is the most probable issue / cause for parity errors that because of the crash the parity drives have not been correctly updated but the data drives and files are OK. Or is it impossible to say or even say anything about probabilities? That is, I am wondering how probable it is that I have lost something valuable. Thank you for any help! Here are the related lines from the log: Feb 2 03:30:01 Tower kernel: mdcmd (38): check NOCORRECT Feb 2 03:30:01 Tower kernel: md: recovery thread: check P Q ... Feb 3 01:30:01 Tower kernel: mdcmd (39): nocheck pause Feb 3 01:30:01 Tower kernel: md: recovery thread: exit status: -4 Feb 3 03:30:01 Tower kernel: mdcmd (40): check resume Feb 3 03:30:01 Tower kernel: md: recovery thread: check P Q ... Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911280 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911288 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911296 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911304 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911312 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911320 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911328 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911336 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911344 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911352 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911360 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911368 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911376 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911384 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911392 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911400 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911408 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911416 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911424 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911432 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911440 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911448 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911456 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911464 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911472 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911480 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911488 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911496 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911504 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911512 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911520 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911528 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911536 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911544 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911552 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911560 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911568 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911576 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911584 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911592 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911600 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911608 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911616 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911624 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911632 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911640 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911648 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911656 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911664 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911672 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911680 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911688 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911696 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911704 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911712 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911720 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911728 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911736 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911744 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911752 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911760 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911768 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911776 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911784 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911792 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911800 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911808 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911816 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911824 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911832 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911840 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911848 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911856 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911864 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911872 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911880 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911888 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911896 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911904 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911912 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911920 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911928 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911936 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911944 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911952 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911960 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911968 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911976 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911984 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543911992 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912000 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912008 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912016 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912024 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912032 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912040 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912048 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912056 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912064 Feb 3 07:40:41 Tower kernel: md: recovery thread: PQ incorrect, sector=24543912072 Feb 3 07:40:41 Tower kernel: md: recovery thread: stopped logging Feb 4 01:30:01 Tower kernel: mdcmd (41): nocheck pause Feb 4 01:30:01 Tower kernel: md: recovery thread: exit status: -4 Feb 4 03:30:01 Tower kernel: mdcmd (42): check resume Feb 4 03:30:01 Tower kernel: md: recovery thread: check P Q ... Feb 4 18:04:58 Tower kernel: md: sync done. time=52497sec Feb 4 18:04:58 Tower kernel: md: recovery thread: exit status: 0

The changes since the first snapshot (i.e., Jul 16) do not contain anything important. So, can I just change the Primary vDisk Location to point to vdisk1.img and delete those ...qcow2 -files? Can the .running -file also be deleted? I have not noticed that before. The output of the snapshots.db -file:

I created a VM snapshot about a month ago. When I tried to delete it I got an error. I then chose Block Commit and it succeeded. However, it just makes the snapshot file larger and does not commit the changes to the base image (i.e., vdisk1.img). Please see the screenshot below. Here one can see, that the system states that there are no snapshots: So, how can I delete the snapshot files and go back to have the vdisk1.img as the only disk image for my VM? All the snapshots have been taken when the VM has been stopped. Thank you very much for the help.

In the Network settings page there is a definition virbr0 gateway (see the screenshot below). I utilize VLANs in my network and I started to wonder whether I should create a VLAN for that because without it the traffic is not routed properly. So, what is the purpose of that gateway/interface? Further, there is another auto created gateway/interface as can be seen below. What is the purpose of that? Thank you for any info on this.

Hi, I am replacing a data disk using the procedure in the manual (https://docs.unraid.net/unraid-os/manual/storage-management/#replacing-a-disk-to-increase-capacity). Is one allowed to shutdown the system and physically replace the old disk with a new one between stopping the array and assigning the new disk to the array? From the manual: --> Is server shutdown OK here after the above action and before the action below?

Thank you for the information!

I have a newly created Win11 VM and for some reason in the VM it shows that the C-drive is thin provisioned. I prefer thick provisioned as I do not want the VM to fill up my cache drive where the VM disk is located. The disk specification part from the VM specification: <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Windows11VM/vdisk1.img' index='3'/> <backingStore/> <target dev='hdc' bus='virtio'/> <serial>vdisk1</serial> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> How can I change the disk to thick provisioned? Or a better option is to somehow make sure that the disk does not get expanded above the set limit (i.e., 64GB). I started to wonder that does Unraid's VM framework make sure of this?

Thank you for the timely reply on this and my other question.

After installing the patch and after reboot I noticed this warning / error in the console output just before "unRAID Server OS version: ..." line: /tmp/inline.sh: line 3: NOT_DELETE.plg: command not found This has not been there before the patch was installed. Anybody else noticed this?

It is like the attached screen capture. Is that as it's supposed to be?

That is, reboot after removing the plugin?