Ksanto

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

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

THANK YOU!

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

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

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

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

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

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

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