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?

I installed the plugin, rebooted and still the tool page says: "No new patches found! The following patches are already installed and will be reinstalled automatically when your server boots" I do not have the Mover Tuning plugin installed and I did not have it have it when I installed the patch plugin. I had the Mover Tuning plugin earlier but uninstalled it a while ago. So, should I reboot my server again or does the above text mean, that patching has been done and it will be done again every time I reboot?

Do you have an ETA for an update where the user can manually install the patches or ignore them? Thank you for your work!

Thank you for the very fast response! Maybe I will go with a "safer" route and purchase an already flashed card like this: https://www.ebay.co.uk/itm/305124908426. From the first port in this thread: In the description of the above ebay item it says "Product line: Megaraid". I have seen "Megaraid" mentioned also in other LSI 9211-8i sales adds. Is there a possible issue? I have understood that LSI 9211-8i cards are good for Unraid.

Thank you for this excellent thread! I have a LSI 9207-8i card in my system and now need to expand it with another card. Getting reasonably priced LSI / Broadcom cards is a bit problematic here where I live. Therefore, I am planning on getting this: https://www.amazon.de/-/en/dp/B07VV91L61/?th=1. Is 10Gtek a good brand? That is, has there been reports against their cards and Unraid? I needed to update the BIOS and firmware of my LSI card. I tried to find BIOS & firmware updates for the 10Gtek card but did not find them. As the 10Gtek card has a Broadcom chip, can LSI / Broadcom firmwares utilized with it?

Merry Christmas and thank you for the excellent work on this container!

Thank you for good information and help! I need an access to custom network and it does not work if I create a temporary docker container with a docker run command. So, I need to create a custom image. In addition to the generic docker tutorial from the link above, is there a good tutorial that would present the unraid specific details for docker containers?

I managed to solve this by creating a separate vlan for the dockers. Now I can block unwanted traffic in my router. Thank you for the help! @SimonF

Thank you for the VLAN pointer! I created a VLAN (br0.40) for the VM and I was able to block any traffic (in the router) from the VM to the unraid server WEB-UI and shares. However, for some reason the access to dockers* still works even though when I block all the traffic from the VM VLAN to the Unraid server VLAN. * Traffic to dockers with 'Host' network type are properly blocked. So, re the 'Bridge' network type dockers communicating directly "inside" Unraid without traffic going through the network router? Any ideas how to proceed?

Thank you for a very fast response! Having the vm in a separate vlan would be ideal but I couldn't do it using my router. That is, it tags the vlan ID based on the network switch port where the device is connected. And as the VM is physically connected to the same port as my Unraid server, I cannot separate the two. Can I somehow allocate a vlan ID in Unraid for all the VM traffic?

I have a VM running on my Unraid host and also some dockers. I need to block the VM accessing specific dockers, the Unraid shares and the Unraid server WEB-GUI. I could not do it with my router (firewall). I guess the VM can access the dockers directly without going through the router. Are there some iptables configuration or some other means to achieve this? Thank you!