itimpi

A non-obvious cause of such an issue that can occur is a problem with the network on the windows system. I had the case where everything seemed to work fine until I tried to copy large files and they would error out with the described symptoms. The fix in my case was to switch to a different network card and since doing so the symptoms have not reappeared.

It is not normal for appdata to contain your media, but merely the Plex working files and as such keeping these on the cache is good for performance. You will have a separate mapping to the plex container for the media and this SHOULD use /mnt/user.

The link on the downloads page appears to be broken. This is covered here in the online documentation. It will be almost impossible to resolve a booting issue unless you have some way of observing it either via an attached monitor or via an IPMI connection (if your motherboard supports it) and of getting at the BIOS settings. Unfortunately this is unlikely to help as it does not appear the booting process is getting far enough to log anything and also the log will not survive a reboot.

No obvious reason that would not work What are you OS are you running the USB.Creator tool on? I tend to just use the traditional manual method myself. What are the exact symptoms when it fails? One thing to watch for is that some BIOS's try to be 'helpful' and reset the device boot order when they spot a new bootable device.

The repair is only running on the specific disk. Assuming the drive has not been marked as disabled (marked with a red ‘x’) then normally you only see reads on the specified drive and writes to that drive and the parity drives. if the disk is being emulated (or getting read errors) then you can will see reads happening on other drives as Unraid reads their contents so it can calculate what the problem sectors on the drive under repair should contain.

Did you make sure to disable the VM and Docker services before running mover? Mover will never move over any files that are currently open.

Both the GUI prompts and the Help text have already been reworked in the 6.8.0 RC series of releases to make the behavior clearer.

Even if you are recovering this time you should always have separate backups of any important files (preferably at least one copy off site) as otherwise they are always at risk.

Have you tried running in Safe Mode with both Docker and VM services disabled? Knowing if the system is stable in such a case might help with knowing where to look for the problem

I do not seem to have that showing on the GUI on my system! Are you sure it is part of the standard GUI and not put there by a plugin?

You are correct in that the license is tied to the GUID of the flash drive and so any replacement drive must have a unique GUID. This should be no problem if using a reputable brand but can be an issue with cheap generic ones where the manufacturer re-uses the same GUID on all their drives. Also it may not be obvious but if purchasing a new drive for use with Unraid you are better of getting a USB2 one as they tend to cause less issues and since it runs from RAM Unraid gets no appreciable speed boost from using a USB3 drive. The process of transferring a licence to a new drive is now automated as described here . Please ask if there are any questions on the process.

There is a known issue in the 6.7.2 release where writing files can adversely affect read performance on other files. This has been rectified in the 6.8 RC release (expected to soon to become the new Stable release)

When a previously working drive shows up as ‘unmountable’ it normally means there is some level of file system corruption. To fix this restart the array in Maintenance mode and then click on the drive on the Main tab and the resulting dialog has options for checking and repairing the file system on the drive. Initially this will run a read-only check which merely reports on what the repair process would do without actually changing anything. To actually fix any reported corruption you need to rerun without the -n (no-modify) flag and if then prompted to do so with the -L flag added. Assuming the repair completes you should now be able to restart the array in normal mode and the drive should mount OK. if you get any output you do not understand ask again for guidance.

What size is your flash drive? Sounds as if you need a larger one. The ‘previous’ folder is where Unraid puts the release that you are currently running as part of the upgrade process from the GUI and it’s contents will be recreated any time you try to run the update from the GUI to allow for reverting to the previously running release. you can update manually by downloading the ZIP file for the release and extracting all the bz* type files to the root of the flash drive. When doing this you can delete the ‘previous’ folder and it’s contents as that folder is only used to support the option in the GUI to revert to the previously running release.

Yes as if the cause is not fixed it is liable to occur again. Maybe you need to check RAM as that is one thing that can cause unexpected corruption.

Well the diagnostics show that currently the docker.img file is corrupt. No obvious reason why this has happened.

There should be no need to format the old parity drive before adding it to the array. The add process will Clear the drive anyway, and when the Clear has finished you will need to format it to prepare it to receive files.

Not sure how you created a share from Windows Explorer? In Windows share names are case insensitive. This can cause a problem if you have two folders at the Linux level with the same spelling but different case.

It is important that you set the Minimum Free Space setting for the cache and the User Shares to be more than the largest file you expect to write. When the free space drops below this value Unraid will stop selecting a drive for new files.

No. They are the copies made after you have filled them in and then started the container.

Make sure you the Previous Apps option in CA if you want the previous settings to be restored. CA stores the settings templates used for previous installs on the flash drive.

Is that really what you set it to? All User Shares start with /mnt/user (note the extra e). Using User shares with docker container mapping is fine.

This would be required.

Open files are never moved. Files for Use Cache set to Yes will be moved from cache to the array. Files for Use Cache set to Prefer will be left on the cache if already there, and moved from array to cache if they are on the array.

Parity does not contain ‘files’ and cannot be used to get files back from lost+found. Working out what files those lost+found file originally related to can be hard work so it is normally easier to restore from your backups. If that is not possible then you have to manually work out what each file in lost+found relates to. The Linux ‘files’ command can help with this as it at least allows for identifying the type of content in each file.