itimpi

I believe that Unraid currently uses the larger of the Minimum Free settings for the cache and the share in deciding if it can use the cache. I personally think these two settings should be independently applied to the cache and the array but at the moment that does not appear to be the case I am not sure if this is intended behaviour or just how it currently works

Chances are that you do not have the plex transcode folder mapped to a location external to the docker image so whenever transcodes are done they are being written internally to the image file.

Chances are that the drivers for GUI mode are not loaded but Unraid is actually up and running. Unraid is designed so it can run headless and for many years that was the only option. Have you tried connecting to it using a web browser from another machine?

The only reason to turn parity off would be to speed up the copy process as writing to the array is slower with parity enabled (parity is real-time). Every time you turn it on these would then be a lengthy parity build process. You either want it on for the whole process so data is protected, or off so copying is faster but data is not protected until you build parity at the end of the copying.

You should post your system’s diagnostics zip file so we can get a better view of how you have things set up.

The parity Swap procedure is not relevant to you as it applies to the special case of having a data drive failed and wanting to use a larger disk as parity and the original parity dtive to replace the failed dtive. In your case there are 2 basic methods I can think of depending on the risks you want to take: quickest is to do a ‘New Config’ and assign all drives to their final positions. You then start the array to build parity based on this new disk set. The downside is that you are not protected against one of your existing data drives failing during this process until the parity rebuild has completed. safer is to first replace the existing parity drive with its replacement and rebuild parity keeping the old parity drive intact until this completes (giving you a fallback option in case of failures during this process). After rebuilding parity to get the array back to a protected state follow the standard process for adding new drives to the array.

The section in your screenshot is part of the Unassigned Devices plugin. You have no unassigned devices present at the moment according to the other screenshot. if I have misunderstood your problem, have you checked that SMB is enabled under Settings->SMB and that User Shares are d able d under Settings->Global Dhare settings (both should be by default).

Chances are that User Shares are not enabled under Settings -> Global Share Settings. This is a known issue with the 6.10.0 rc1 release that is fixed for the rc2 release.

If you have a single parity disk and any drive (including parity) fails then the check will instead run as a read-check of the remaining drives and ignore the write corrections to parity settino. TIP: if you have the Parity Check Tuning plugin installed then the parity check history entries will contains additional information such as what type of check was actually run.

Are you saying that you cannot write to the USB even if you plug it into a PC/Mac? If so it is almost certainly failing.

You go to the shares tab to set up shares and then specify whether that particular share should be visible on the network, and what security you want applied for network access. You just get the /dev/disk/by-id/? type name for the drive and set that up where you currently specify the vdisk filename in the VM settings. You also make sure that at the Unassigned Devices level you set the “Passed through” setting so that UD will not try and mount it (which would interfere with the VM using it).

If you are dedicating a complete SSD to each VM then I would not bother to use a vdisk at all - just pass the whole SSD through to the owning VM. It seems at the moment you have a vdisk file that is larger than the SSD on which it resides? Vdisks are allocated as ‘sparse’ files at the Linux level which means the actual space used can be less than the physical space as space is only allocated as the guest OS writes to different parts of the vdisk. This means that over time the vdisk file can gradually grow towards its maximum size. When you run out of space on the physical drive holding the vdisk that VM will then fail although since the values are very close you may never reach this point). to add a network share you do it inside the VM and navigate to the address of the UnRaid server where you will see all network shares that you have set up on the UnRaid server. You want to use a network share any time you want files to be seen by more than one VM/PC/Mac as vdisks are dedicated to a VM. no idea about your USB speeds. The values you quote seem that it may be functioning as a USB1 type device.

I think if you use it as an Unassigned Device then you would probably be OK as the UD plugin can handle devices disconnecting and then reconnecting (not atypical with USB drives). If used as a cache (pool) drive in the UnRaid sense then I suspect you could encounter problems but you could try it to find out. The problem with using it as a UD device is that it cannot then participate in User Shares - not sure if think this will matter for you?

Why did you use Prefer? This means you do NOT want files to be moved to the array if there is room for them on the cache so it is not surprising the cache drive fills up. If you want them to be moved to the array by mover then you need to use ‘Yes’ instead. There is help built into the GUI on how the various options for thenUse Cache setting work, and even more detail in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

What do you have set as the Poll interval? The GUI only updates the disk status at that frequency.

You should provide your system’s diagnostics zip file after attempting a format so we can see what is happening.

They are incompatible with each other. Passing a drive through to a VM removes it from Unraid control when the VM starts. Perhaps if you explain why you both want to mount the drive at the UnRaid level and pass the drive through to a VM we might be able to suggest a better approach.

The problem is not a lost disk, but file system corruption. the general case for handling this is described here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

This in principle. note that it is the last folder before a cutover to another disk, not just the last folder on the whole drive.

You should run a check/repair on the file system for disk 3. You might want to also check the power/SATA connections to the drive are firmly plugged in. if the problem persists post your system’s diagnostics zip file.

I know there is a setting you can make at the Mac end to tell MacOS to not create dot files on network drives.

If SMART tests fail a disk should always be replaced. The converse is not always true in that a disk that passes the SMART tests is not always OK (although it is the vast majority of the time).

I would say at this point your best bet is something like UFS Explorer on Windows.

Are you using a Mac as it has a tendency to create .xxx type files unless you disable this for network drives and it is possible the unexpected presence of one has triggered some strange behaviour? If so then it sounds like something that should be fixed at the Unraid level to ignore such files.

I believe that Linux systems expect the BIOS time to be set to the UTC time with the Linux level handling the time zone which would explain the behaviour you are seeing?