itimpi

There is nothing I know off that prohibits the flash drive from being accessed over the network (I do it all the time). You should click on the flash drive on the Main tab and check whether you have set it to be available via the network (as the ‘flash’ share) and what access permissions should be applied to network access.

It definitely looks like a disk with problems. As well as the Extended SMART test failing the disk has a lot of reallocated sectors - not a good sign.

This is a bit confusing - the docker image file is not stored on /boot (which is the Unraid flash drive). The flash drive mounted at /boot uses a FAT32 file system that has limited support for Linux level permissions. In addition setting ‘executable’ option on all files located there is not allowed for security reasons.

The most likely cause for such a slow build of parity is a connection issue due to a cabling/power issue that is causing a drive(s) to continually reset. We would need a copy of your system’s diagnostics coveting a period when this is happening to see if this actually did appear to be the problem.

It is recommended that the automatic parity checks are set to be non-correcting so a drive that is misbehaving (that you have not yet noticed) will not end up corrupting parity and thus prejudicing your chance of recovering from drive failures without data loss. You then only use correcting parity checks that are started manually and when you do not believe you have any problem drives but may have some parity errors that need correcting (e.g. after an unclean shutdown).

A sync error is one where the contents of a given sector on the parity drive do not agree with the results of the parity calculation applied after reading the corresponding sectors from all the data drives. If running a correcting check the parity drive sector is then overwritten with the results of the parity calculation on the basis that the data drives are to be considered correct. A small number of these are expected if you have had unclean shutdowns. it is normally recommended that scheduled parity checks are set to be none-correcting. The rational is that if a drive is reading unreliably and you have not yet noticed this then you do not want it polluting the contents of the parity drive and thus potentially prejudicing the chance of recovering after a drive failure without data loss. If you get a non-zero result from a scheduled check then you should first make sure you do not have a current hardware issue, and if you are happy then manually run the correcting check.

As far as using files is concerned it is transparent as to whether files for a User Share are on the main array or on a cache pool if you are accessing them via the User Share system. Unraid User Shares provide a consolidated view of files in a user share regardless of whether they are currently resident on the main array or a cache pool associated with the share. For the Use Case you mention you do not need to know if the files are currently on the main array or a cache pool. You can always run mover,manually but that does not seem to be needed for the Use case you mention. you can also,by-pass the User Share system for placing files by transferring files directly to a specific drive, and they will still appear under the appropriate User share as long as you put them into an appropriate directory.

Not sure there is a description of the sort you mention you mention. There is also,a,bit about parity in the ‘Getting ‘started’ section of the online documentation but that is probably at the same level,as,the link you mention. The source of the md driver that implements parity at the LInux level in Unraid is provided with Unraid but that would be rather hard to,peruse. You will probably just have to,ask,questions to clarify any point that you think needs it.

Have you checked the IP addresses on your phone and laptop. You do not want both client and server to be on the same subnet as this can cause routing issues. I deliberately set my home subnet to be something other than 192.168.0.x or 192.168.1.x as this would mean there is a good chance of both client and server ending up on the same subnet.

As well as containing the files for booting Unraid, the USB is also part of the licensing mechanism, and it also store all configuration information for the customisations a user makes to their Unraid setup.

Are you trying to boot in UEFI or legacy mode? if trying UEFI mode make sure the EFI folder on the Unraid flash drive does not have a trailing ‘~’character if trying legacy mode make sure that CSM option is enabled in the BIOS.

It does not matter - Unraid recognises drives by their serial numbers. The sdX ids are assigned dynamically by Linux during the boot and can never be relied on and are subject to change between reboots

Yes it is a RAM tester. To run it you select that option from the Unraid boot menu.

Without any more information about exactly what you did and without your system’s diagnostics you are only going to get guesses I suspect that rebooting the system will bring share back.

Not that I know of unfortunately

How did you move the file? Depending on how you moved it you may be falling found of this quirk of how User Shares can interact with the Linux level underlying Unraid.

You should provide a copy of your diagnostics so we can get a better idea of what happened. It would also be a good idea to provide a copy of /etc/cron.d/root so we can see how the schedule has been set. BTW: It is normally recommended that scheduled checks are set to be non-correcting.

The only thing you have to do to enable UEFI boot is to remove the trailing ‘~’ character from the EFI folder on the Unraid flash drive. the one thing to note is that if you are passing any hardware through to a VM then the hardware ‘iD’s will have changed on the new hardware and will need adjusting to match the new hardware. You should delete (or rename) the config/vfio.cfg file on the flash drive to stop inadvertently mapping the wrong hardware (and possibly causing issues) on the new system.

Do you have the client on a different sub-net to the Unraid server? If not you are probably encountering routing issues.

Looking at your screenshots you have mapped /transcode to /tmp (which is in RAM rather than /mnt/user/tmp which the guide suggests which is a User share called ‘tmp’ on physical media. If you have sufficient RAM then this might be OK to get best performance, but even then it should be a sub-folder of /tmp (e.g. /tmp/plex) to avoid issues.

Unraid will not do that - you must have configured something to make that happen. The most likely culprit I can think of is the CA Backup/Restore plug-in being incorrectly configured to point to that location for storing backups. the only way I can think of to recover the data will be to restore it from your backups.T

Worth noting that for initial data load it is normally recommended that you do not bother to use a cache drive but go straight to the array.

can’t think of any reason why not as long as that machine has a 64-bit capable processor unless it is not capable of booting off a USB device.

You might find this section of the online documentation that can be accessed via the Manual link at the bottom of the GUI illuminating as to why you will never get anything close to drive speeds when writing to an Unraid parity protected array.

The .key file should still be valid. Make sure it is installed into the ‘config’ folder on the flash drive.