itimpi

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Have you set any of the shares to be visible on the network (I.e. the Export option) under the share settings. I believe by default they are not on current Unraid releases.

It looks like your last SMART extended test failed which suggests the disk needs replacing. You could try running it again to confirm (but disable spindown on the drive before starting the test).

How much RAM do you have on the server? You need a minimum of 4GB to successfully update via the GUI. If you have less than that you will need to use the Manual upgrade process as described in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

Chances are that the flash drive dropped offline for some reason.

That setting means you want any new iso files to be written to cache, and later transferred to the array. The rational being if you have just downloaded an iso for a new VM you may temporarily want maximum performance. for files you want to keep on the cache the setting would be Prefer or Only. the help built into the GUI describes how the various values for the setting work and how they interact with the mover application.

What have you tried and what Apple device types are you using? If you have multiple Apple devices have you set inFuse to sync its settings between them via iCloud. There should be no problem doing this as I use inFuse from my iPad, iPhone and Apple TV all accessing the media off my Unraid server.

The New Config tool should not be that scary as long as you start with the option to keep all the current assignments, and then return to the Main tab and simply unassigned the disk you want to remove prior to starting the array to commit the change and rebuild parity based on that change.

There is no way to speed up the parity check simply by changing some settings as its speed is determined by the hardware capabilities of your system. Normally the limiting factor is the speed of the slowest drive in the array, although it is also possible for the way the drives are connected to have a limiting effect. You also want to ensure that no other disk accesses are being made to the array at the same time as in such a case both of them have their performance adversely affected. If you have large drives then it may be worthwhile installing the Parity Check Tuning plugin to at least restrict the check to running outside prime time.

If the files already exist on the array then mover will not move them. From your description it sounds like this might be the case.

That would only work for parity2 if the disks were in the same order. Not clear if this was the case.

I suspect that is the time that you have mover scheduled to run and that activity associated with that is causing the issues.

I do not see any reason why those settings will not work. I use something similar when doing development/testing of the plugin. If you want me to look any further then you should enable the ‘Testing’ mode of logging in the plugin and let me have the resulting logs ( via diagnostics). As was mentioned there is no way that running a parity check should cause a system to crash unless you have some sort of underlying hardware issue.

In the worst case the approach detailed here in the the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page could help.

That will be because when you make that sort of change Unraid restarts Samba so any transfer in progress at the time gets aborted. There has been discussion about changing this to just tell Samba to reread its configuration file but as far as I know that has not happened and I do not know of any immediate plans to make such a change.

Did you actually disable the services rather than having no VMs or containers actively running? The services hold files open which will stop them being moved.. If it is not that then you may have file system level corruption on the old pool.

Mover will not move files between pools. If you want to use mover then it needs to be done in 2 stages - the first to move the files from the old pool to the array, and then a second one to move the files from the array to the new pool. probably easier (and quicker) is to manually move the files between the pools.

You said that you are using a iinux VM ? I wanted to check that the folder within the VM that you are trying to mount the share to actually exists as the error messages suggest it may not.

You are likely to get better informed feedback if you attach your Unraid system’s diagnostics zip file to your next post in this thread so we can see how you have it configured. also, do the directories you are trying to use as mount points at the Linux end exist?

The extended check only updates every 10%. The check will typically take around 2 hours per TB so that can give you an estimate as to when you will see the percentage update.

The process is covered here in the the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

I wad trying to say that those settings are fine unless you have some special requirements..

it is basically up to you to decide how you want the share to be handled - there is no right or wrong as it depends on what you want. You would normally want backups on the array so you typically do not use a pool. In terms of which drives to use that is up to you. The share can be configured to use a specific drive or allowed to spread over all drives. The settings shown in the screenshot are not atypical.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread so we can check how you have things set up.

Why is this surprising? If you have the Only option set then Unraid will attempt to put files on the pool regardless of the amount of space free and you will then get an error if a file does not fit.