... or at least not setting the origin as Secondary?

Hi everyone,

New user here, as you might have guessed.

I found myself dumbfounded when I discovered that none of my new shares were bound to the origin of their content. I noticed this when I activated the SMB export to gain network access (which is totally fine, but if I hadn't have to do that, I wouldn't have discovered or expected this behavior at all).

From my research beforehand, I know this is a highly discussed topic. However, I have yet to find a logical explanation or wrap my head around why the system doesn't ensure that new files in a share land (at least in the last instance) where the other files already reside.

If anybody can point me to a coherent explanation (perhaps from the developers?), I would be very grateful. Maybe there is something within the core logic of Unraid that technically would requires an extra step?

Regards

Ksanto

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.

Thank you.

In this situation, I would not know what diagnostics to provide to make a problem with the logic of Unraid clear, but I will try to explain:

I installed Unraid 7.3 on an SSD and added an array later. The array was filled with root folders from a TrueNAS instance. All of these folders were automatically bound as shares. So far, so good and expected. What I did not expect is that by default, the shares were not bound to their origin on the array, but to the SSD (the cache). Nor was the array bound as secondary, which meant the mover was not active due to this fact.

Hope this makes it clear.

Regards

Ksanto

It sounds like you created the Shares on the cache drive. A Share is automatically created whenever a folder/directory is created in the 'root' of a drive that is part of a cache or the array. Let me point you first to this section of the Unraid docs:

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#user-shares

This is 'official' way to create a share BUT that backdoor way of creating a folder/directory also exists. It can bite the unwary if you don't realize that Unraid can be configured to have Primary and Secondary storage location. See here for that:

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#primary-and-secondary-storage

Why us this primary/secondary option available? It is because writing to cache location first is (at least) twice as fast as writing directly to the array! But it does require that you configure the Share properly to use this option. (If you use the backdoor, you have to go looking for these settings.) If you create the share using the instructions in the first link that I provided, the settings are presented to you to set when you create the share.

Edited May 30May 30 by Frank1940

1 hour ago, Ksanto said:

what diagnostics to provide

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.

hi Frank1940,

Thank you for your extended reply. No, I did not "create" the shares "on" the cache drive, at least not the content. The configuration data maybe, but I am not familiar enough with the structure of Unraid for that, as you can see. As you mentioned, even though it wasn't explicitly documented, the shares were automatically created once I copied the folders over.

But at its core, your answer would mean that the process defaulted to the cache as its primary storage location because I indirectly created the shares by creating (copying) folders onto the array, instead of using the official way of configuring them beforehand. This makes the cache simply the preferred or default location.

But wouldn't it still be more rational to assign the point of origin as the default primary location for the share? I did not read that far into the documentation when I copied the folders and was pleasantly surprised that all shares were already present.

I did not realize this was a hidden feature. If it is not, this should be added to the documentation—especially the fact that it defaults to the cache as primary. I will check if it is possible to add this to the documentation and will suggest a change in the behavior.

Regads

Ksanto

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).

Diagnostics might still give us enough information to try to understand what happened.

What you describe isn't really the way things work.

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.

3 minutes ago, trurl said:

The word diagnostics in your post and mine and everywhere it appears in the forum is a link explaining how to get diagnostics.

Sorry, I meant that more semantically than literally. After all, the diagnostics will only show if Unraid is working according to its own blueprint. But if the blueprint itself is flawed, the logs will report 'everything is perfect,' even though the behavior makes no sense to me and wouldn't help you see what I'm seeing.

Anyway, here are the diagnostic files.

Regards

Ksanto

Unraid-diagnostics-20260530-1347.zip

@Ksanto , I agree with @trurl. I am wondering how you created a share on the cache drive without creating a Share. I suspect you must have been working down at the Linux level. It seems to me that transfer from TrueNAS is often done by using Linux tools like rsync (or one of its derivatives) to do the move.

I have a suspicion that you might also be using Disk Shares rather than User Shares. Disk Shares are described here:

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#disk-shares

Note these precautions if you are using Disk Shares:

Thank you trurl,

but I do not know what you are talking about. I never created any shares. I simply copied folders and there content from an unassigned (former Truenas Drive) to the empty array (I think it was with rsync), and the shares were already configured when I went to the settings. They were configured as described: with Cache as Primary, nothing else.

Regards

Ksanto

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.

Just now, trurl said:

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.

That is, of course, after I corrected the settings, as I mentioned in my opening post when I found myself dumbfounded. That is what I meant when I said I don't know if the diagnostics can help with this. If they are not able to show what happened at the exact moment the folders were created on the array, they are worthless.

Regards

Ksanto

Edited May 30May 30 by Ksanto
typo

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.

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

8 minutes ago, trurl said:

You have one share without any settings, shown in diagtnostics 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.

That is actually the Applications folder from TrueNAS, one of the folders, but this one I will not need in the future, which is why I didn't configure it further. If I go into the settings, it shows me the following:

Yes, 'the share doesn't have any files on cache', at the moment! But as the English hint windows shown on my German system (sorry for that) suggest, all NEW files would be written to the cache instead of the origin of the folder, the array, which is the whole topic here.

Regards

Ksanto

Edited May 30May 30 by Ksanto

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.

THANK YOU!

In Unraid writing to the array is much slower than writing to a pool. It is therefore not uncommon to want to 'cache' new files initially and let them be transferred to the main array during overnight idle time. This is what the share setting of Primary=poolname ('cache' being the default pool name for historical reasons), Secondary=array and mover direction poolname->array achieves. If you do not want any caching to happen then you simple set Primary and no Secondary.

This is all covered in the online documentation.

BTW: When you provide diagnostics it allows us to see how you currently have the system setup which helps with providing helpful feedback in response to questions.

1 minute ago, itimpi said:

In Unraid writing to the array is much slower than writing to a pool. It is therefore not uncommon to want to 'cache' new files initially and let them be transferred to the main array during overnight idle time. This is what the share setting of Primary=poolname ('cache' being the default pool name for historical reasons), Secondary=array and mover direction poolname->array achieves. If you do not want any caching to happen then you simple set Primary and no Secondary.

\this is all covered in the online documentation.

I didn't question that, nor was it ever the core of the Topic. trurl has already acknowledged it as a bug.

Regards

Ksanto

I have created this bug report:

https://product.unraid.net/p/creating-top-level-folder-on-array-disk-results-in-cache-only-user-share

Thank you! I was looking into it when I noticed that you had already done that. I will provide the diagnostics file from this thread and identify myself as the original user.

Thanks again, and have a nice day!

Regards

Ksanto