itimpi

I think there is also a bug in 6.10.0 rc2 where changes to share settings do not take affect until the array is next started.

I suspect nobody knows which is why there has not been an answer.

What is transferring the files between the two shares? It sounds like you might be experiencing the behaviour described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI.

It is not the resolution of the movie that matters, but the bit rate for a given file. Have you checked the bit rate of the file(s).

No idea exactly what is causing your problem. the only time I got similar symptoms it turned out in the end to be the network on the Windows client that was failing under heavy load.

I believe the ability to remove servers is a feature that still needs to be implemented.

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.