trurl

According to diagnostics you have 3 user shares that no longer exist because they have no contents: B-----s shareUseCache="no" # Share does not exist d--a shareUseCache="yes" # Share does not exist m-----l shareUseCache="no" # Share does not existDo you think these should have contents? These user shares do exist: appdata shareUseCache="only" # Share exists on cache, disk1, disk2 m---a shareUseCache="no" # Share exists on disk1, disk2, disk3, disk5, disk6, disk7, disk8, disk9, disk10, disk11, disk12, disk13 system shareUseCache="yes" # Share exists on disk1I assume m---a is your media share Unrelated, your appdata and system shares have files on the array. In fact, you have system configured to be moved to the array. Better if these are all on cache or other pool with nothing on the array, so Docker will perform better, and so array disks can spin down since these files are always open.

If it works in SAFE mode but not otherwise then a plugin is the likely cause. You can disable individual plugins by booting in SAFE mode and deleting any .plg files in config/plugins, or just rename them so they aren't .plg files. What happens if you disable the user scripts plugin using that method then boot in normal mode?

You cannot use just any cable with your modular PSU. Modular PSU pinouts are not standardized. You must use cables specifically for that PSU. Many people have fried drives by trying to use an incompatible cable.

Have you tried booting in SAFE mode?

Start a new thread in General Support with your Diagnostics.

Attach Diagnostics ZIP to your NEXT post in this thread.

Start your own thread with your diagnostics.

Start your own thread with your diagnostics

That's what I would recommend. Will you use TPM for license?

Attach Diagnostics ZIP to your NEXT post in this thread.

This is no different than transferring your license to a new USB flash drive. The previous licensed flash drive can't be used for an Unraid license again.

I have created this bug report: https://product.unraid.net/p/creating-top-level-folder-on-array-disk-results-in-cache-only-user-share

I have reproduced this behavior on 7.3 by using the command line to create a top level folder on disk1. It results in a new share. The settings for that share show Primary:cache; Secondary:none. However, no .cfg file is created for that share. And, if I create a folder in that test share, it is created on cache. This is not the way it is supposed to work.

To answer the question in the title of this thread. There is no rational for that behavior since that is not what happens.

I guess there is no evidence that would demonstrate what you think happened then. Maybe you could try to reproduce and if it happens again, post the evidence. Default setting for a share (except for appdata, domains, system) is to not use cache, and that would especially be the case if a top level folder were created on the array.

What user share, for example? appdata and system user shares are on cache and set to only store on cache. This is a good setting for these shares. All other shares have no files on cache, but many are set to Primary:cache; Secondary:array; Mover action:cache->array. This is the usual setting to allow files to be cached and later moved to the array. You have one share without any settings, shown in diagnostics anonymized as A----------s shareUseCache="no" # Share exists on disk1 This is what would happen if you create a top level folder on array or pools. It is a share with default settings, which is to not use cache, and the share doesn't have any files on cache.

I have split your post into its own thread since it isn't clear if the OP of that other thread is still using it for his problem. Better to keep things separate so there is no confusion giving advice when data is at risk.

Another possibility that might be the reason for some difficulty in accurately describing what is happening. Maybe you have accidentally created shares with the same name except for upper/lowercase. Linux is case-sensitive, so Media and media are different shares. But this can cause some problems configuring a share since the .cfg files for those settings are on flash and those .cfg filenames are not case-sensitive. Diagnostics would let us check whether that is happening.

Diagnostics might still give us enough information to try to understand what happened. What you describe isn't really the way things work.

When you create a top level folder on array or pools, it is automatically a share named for the folder. If you don't make settings for the share it has default settings. The default setting is to not use cache, but I'm not sure what happens if you create the folder on cache, maybe it defaults to primary cache, secondary none (cache-only).

The word diagnostics in your post and mine and everywhere it appears in the forum is a link explaining how to get diagnostics. The complete diagnostics ZIP file is what we are asking for.

Maybe Diagnostics would help us understand what you are seeing. Attach Diagnostics ZIP to your NEXT post in this thread. Also tell us the name of the share.

That is the wrong command. For a disk not in the array, you must specify the partition, such as /dev/sdb1. But, for a disk in the array, you must specify the md device, such as /dev/md1p1, or you will invalidate parity. Better to use the webUI, it will use the correct command. What do you get from command line with this? fdisk -l /dev/sdbStart the array in normal (not maintenance) mode and post new diagnostics.

Is your license still with your flash drive? Or did you do TPM?

Basically, you have to erase the existing partition before it will let you repartition during onboarding.