itimpi

This is documented here in the online documentation

What browser are you using? It sounds like the browser you are using is not compatible with the latest version of NoVNC.

Thanks for the feedback. Deleting just the /mnt/user/appdata/dropbox/.dropbox-dist folder did not work, but deleting /mnt/user/appdata/dropbox/ and then relinking my Unraid server to my Dropbox account works fine and I am back in operation. EDIT: Looks like I spoke too soon as after running for a few minutes after linking the Unraid server to my Dropbox account the same error occurred. It would be great if you could produce an image that fixes this issue.

This is due to a change in the security that came in with Unraid 6.8.x series where files on the flash drive are no longer allowed to hav execute permission. You can get around this by preceding the script name with the ‘bash’ command. E.g. bash unRAIDFindDuplicates.sh -v

A hard link is merely another directory entry pointing to the same file. If it did NOT show the same size then you would have a serious problem. The overhead of the hard link is the extra directory entry.

The settings for a container are not stored in the docker.img file but are stored on the flash drive as an XML template in the CA plugin’s folder. This template is used if you re-install apps via Apps >> Previous Apps so your settings remain intact. This makes it very easy to rebuild the docker.img file with all container settings intact.

I tried deleting the image and then redownloading it but I get the same error. I also tried using the freeze tag but that did not change things. Is there sokething else I can try?

The SMB version of 4.11.4 is much more recent than 4.3 (11 > 3) so you have some other issue than the SMB version.

I tried that link and the wiki page that resulted tells you what files need changing/removing on the flash drive to clear the current password for root.

The article you mention is part of the “unofficial” documentation. The official documentation on repairing file systems is found here.

I've just updated this container and I now get the following appearing in the log: dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-94.4.384/apex._apex.cpython-37m-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-94.4.384/tornado.speedups.cpython-37m-x86_64-linux-gnu.so' dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-94.4.384/PyQt5.QtWidgets.cpython-37m-x86_64-linux-gnu.so' Traceback (most recent call last): File "dropbox/client/main.pyc", line 262, in <module> File "dropbox/foundation/navigation_service/factory.pyc", line 19, in <module> File "dropbox/foundation/navigation_service/navigation_service_impl.pyc", line 57, in <module> File "dropbox/foundation/html_views/electron/manager_factory.pyc", line 13, in <module> File "dropbox/foundation/html_views/local/common/manager.pyc", line 33, in <module> File "dropbox/client/features/model_registry.pyc", line 13, in <module> File "dropbox/client/features/generated_models.pyc", line 279, in <module> File "dropbox/client/features/previews/view_anchor.pyc", line 104, in <module> File "<_bootstrap_overrides>", line 153, in load_module ImportError: libglapi.so.0: cannot open shared object file: No such file or directory !! dropbox: fatal python exception: File "<_bootstrap_overrides>", line 153, in load_module ImportError: libglapi.so.0: cannot open shared object file: No such file or directory !! dropbox: fatal python exception: ['Traceback (most recent call last):\n', ' File "dropbox/client/main.pyc", line 262, in <module>\n', ' File "dropbox/foundation/navigation_service/factory.pyc", line 19, in <module>\n', ' File "dropbox/foundation/navigation_service/navigation_service_impl.pyc", line 57, in <module>\n', ' File "dropbox/foundation/html_views/electron/manager_factory.pyc", line 13, in <module>\n', ' File "dropbox/foundation/html_views/local/common/manager.pyc", line 33, in <module>\n', ' File "dropbox/client/features/model_registry.pyc", line 13, in <module>\n', ' File "dropbox/client/features/generated_models.pyc", line 279, in <module>\n', ' File "dropbox/client/features/previews/view_anchor.pyc", line 104, in <module>\n', ' File "<_bootstrap_overrides>", line 153, in load_module\n', 'ImportError: libglapi.so.0: cannot open shared object file: No such file or directory\n'] (error 3) Any thoughts on how to fix this?

The time for a parity check is dependent primarily on the size of the largest parity drive - the sizes of the data drives has little effect. The time you quote of 26 hours sounds not atypical for a 12TB parity drive - typically one estimates 2-3 hours per TB. It is just that it takes a long time to read 12TB of data (since parity check reads every sector on the parity drive). One of the reasons for the development of the Parity Check Tuning plugin was the fact that with the size of modern large drives there is no way of completing a parity check fast enough to avoid it impacting ones daily use.

It has to be UNRAID (I.e. all capitals) or it will not be found. the ‘df’ command output confirms that the flash drive is not mounted and until that is resolved you will not get your network up as the drivers and configuration need to be loaded from the flash drive. if you have a choice of USB ports then a USB2 one is preferred. Some BIOS’s seem to not be too reliable in their handling of USB drives during the boot process - particularly when using a USB3 flash drive in a USB3 port.

The video seems to show that Unraid is failing to find and mount the flash drive during the second phase of the boot process. Have you checked that it has a label of “UNRAID”? You can check if this is the case by logging in on the console and using the ‘df’ command to see if it shows the flash drive mounted at /boot.

There is a good chance that a file system repair can be done on the original drive so that it can be mounted again.

Have you still got the original drive? If so it might be possible to retrieve files from there?

You probably want to do this

One non-obvious thing to check is that the HBA is firmly seated in the motherboard slot. If it has slightly worked its way out due to vibration you can get symptoms of drives unexpectedly failing as a momentary disconnect happens to the motherboard.

The parity check always runs to the full size of the parity disk regardless of the size of the data drives. This is why the time for a parity check is basically dependent on the size of the parity drive - not of the individual data drives in the array. As was mentioned this is to ensure that all of the parity drive beyond the size of the largest data drive contains zeroes so that you can later add larger data drives and keep parity valid

Yes - the second check is reporting how many parity errors it has corrected. It is a GOOD sign that the number was the same as was reported by the non-correcting check. You could it your really want to now run another non-correcting check to prove the count is now zero but that is not really necessary.

I have edited the text in the wiki entry you mentioned to make it clearer that the error message only occurs if you are running a Trial licence and have no internet connection. I have also mentioned explicitly that no internet connection is required if using a paid-for licence.

An internet connection is required if using a Trial licence. No internet connection is required if using a paid-for licence.

Many people do not have routers with VLAN capability.

Not if I understand you correctly A docker/VM that uses virbr0 can connect to dockers/VMs using br0, but the converse is not true.

br0 will give addresses that are directly visible on the LAN and can accept both incoming and outdoing connections. virtbr0 is a NAT style bridge that only allows outgoing connections with the devices behind it NOT being directly visible on the LAN.