not work in china, it's not a smart os, to hard for starter

install plugins store,  show sll fail

On 11/14/2024 at 11:48 AM, rh535 said:

After I press install, the pop-up "Choose A Branch To Install" appears. I am unable to select anything, and my clicks do nothing. I can see the text change when I hover over an option, but it doesn't actually do anything. The cancel button works, though.

Sorry about that guys.  Fixed...

It seems when a share is marked as exclusive and a new template is installed the default pathing is incorrect due to CA pulling the symlink target and not the symlink link_name.

 

eg; exclusive access for appdata residing on a pool called cache; /mnt/cache/appdata vs the proper /mnt/user/appdata

16 hours ago, Squid said:

Sorry about that guys.  Fixed...

Thank you! This fixed my issue!

12 hours ago, DiscoverIt said:

It seems when a share is marked as exclusive and a new template is installed the default pathing is incorrect due to CA pulling the symlink target and not the symlink link_name.

 

eg; exclusive access for appdata residing on a pool called cache; /mnt/cache/appdata vs the proper /mnt/user/appdata

For a mapping that is /config (ie: most container's appdata), then the template system automatically adjusts that host mapping to reflect whatever you have set in Settings, Docker Settings, default appdata path.

 

Either way, what's the difference or trouble that you're having?  On an exclusive share sitting on the cache drive, both references are identical and valid.  For any default template that has a mapping that is not a container path of /config but has a default host path that is set to be the Unraid default path for docker appdata, then CA adjusts that path to match whatever you have currently as the default appdata path

I checked this morning and for example this template with my settings of /mnt/user gets changed to /mnt/cache.

 

 

 

We always recommend people keep /mnt/user to avoid problems the day they change their storage layout, it used to be that going directly to /mnt/pool had a performance improvement but now leaving /mnt/user and using exclusive shares is preferred.

 

2 hours ago, Squid said:

For a mapping that is /config (ie: most container's appdata), then the template system automatically adjusts that host mapping to reflect whatever you have set in Settings, Docker Settings, default appdata path.

 

Really not a fan of those hidden and pretty much undocumented conditional behaviors, especially as the /config location is far from a standard... looking at my containers only about 30% of them have their appdata in /config

Edited November 21, 20241 yr by Kilrah

1 hour ago, Kilrah said:

looking at my containers only about 30% of them have their appdata in /config

Which is why CA / dockerMan has to adjust the paths.  Because if the user decides to map their default appdata path as "Appdata" instead of "appdata" now you've got two shares identically named.  Or if you want it stored within a different share altogether.  Or what about the templates where the template explicitly references /mnt/cache/appdata, but the user doesn't have a pool named "cache", so it gets created in RAM and subsequently lost without any adjustments happening?

 

Or similarly where user shares are not enabled, should the template system have everything automatically going to RAM?

 

But, for what it's worth, dockerMan (template editing screen) is dereferencing the path itself, and it is correct.  

 

The behaviour of /config entries automatically being overwritten has been in place for probably 10 years.

 

But, let's use SearX as a better example.  You've got /etc/. with a default value of /mnt/user/appdata/searxng/. For the users that have chosen to change their default appdata path to say /mnt/user/system/appdata or who have it on an unassigned device, that setting is going to wind up creating a new appdata share unless the user automatically changes it.

 

dockerMan has been doing this forever on /config.  CA just started on everything else for what is referring to the appdata share.  (And inadvertently you found a bug, since CA only adjusted things in the value, not the default if there was no value)

 

Shouldn't the OS automatically adjust the settings to match what the USER has specified?  Or is the paths that the maintainer chosen for where to store the appdata and the references be what is forced onto every user, and effectively forcing them to conform?

 

 

 

1 hour ago, Squid said:

Which is why CA / dockerMan has to adjust the paths.  Because if the user decides to map their default appdata path as "Appdata" instead of "appdata" now you've got two shares identically named.  Or if you want it stored within a different share altogether.  Or what about the templates where the template explicitly references /mnt/cache/appdata, but the user doesn't have a pool named "cache", so it gets created in RAM and subsequently lost without any adjustments happening?

 

Or similarly where user shares are not enabled, should the template system have everything automatically going to RAM?

 

But, for what it's worth, dockerMan (template editing screen) is dereferencing the path itself, and it is correct.  

 

The behaviour of /config entries automatically being overwritten has been in place for probably 10 years.

 

But, let's use SearX as a better example.  You've got /etc/. with a default value of /mnt/user/appdata/searxng/. For the users that have chosen to change their default appdata path to say /mnt/user/system/appdata or who have it on an unassigned device, that setting is going to wind up creating a new appdata share unless the user automatically changes it.

 

dockerMan has been doing this forever on /config.  CA just started on everything else for what is referring to the appdata share.  (And inadvertently you found a bug, since CA only adjusted things in the value, not the default if there was no value)

 

Shouldn't the OS automatically adjust the settings to match what the USER has specified?  Or is the paths that the maintainer chosen for where to store the appdata and the references be what is forced onto every user, and effectively forcing them to conform?

 

 

 

 

The issue is that CA/dockerMan is not respecting the host default.

 

In an exclusive share scenario the symlink target overwrites the template entry.

 

As an aside. Any developer doing a commit to make the template default to /mnt/cache or similar should be flagged for blacklisting.

 

I potentially put this into the wrong channel as it sounds more like a dockerman issue and not CA?

 

Edited November 21, 20241 yr by DiscoverIt

The code in question has been in since at least 2018 (I stopped at that point looking back further), and resolves the symlink.

 

I'll see if it can get removed, but bear in mind that what it does show is technically correct.

Understood but why would it be correct when up until recently the usage of exclusive shares was not a thing? If the user specifies in the global setting level the usage of /mnt/user/appdata I wouldn't expect it to resolve instead to /mnt/cache/appdata when /mnt/user/appdata is still a valid location. With exclusive share off for appdata the resolving occurs as expected and uses /mnt/user/appdata.

 

I could see it resolving differently if the global setting was /mnt/zfs_cache/appdata and the user really has /mnt/cache/appdata so its instead resolved to /mnt/user/appdata.

 

 

4 hours ago, Squid said:

Or what about the templates where the template explicitly references /mnt/cache/appdata, but the user doesn't have a pool named "cache", so it gets created in RAM and subsequently lost without any adjustments happening?

That's the thing, we regularly get people on Discord to whom that happens regardless usually after configuration changes, so while it comes from a good intention it is not all-encompassing. If you have an invalid situation it should throw an error and not let you continue at all before it's fixed instead of being silently patched and going through anyway leading to a situation where people think it's ok only to realise way later it was not.

 

Agree templates that reference "cache" should be blacklisted. As mentioned by @DiscoverIt some were for performance benefits and most of them would probably be from before exclusive shares existed and are probably unmaintained if they weren't updated.

 

4 hours ago, Squid said:

if the user decides to map their default appdata path as "Appdata" instead of "appdata"

 

4 hours ago, Squid said:

For the users that have chosen to change their default appdata path to say /mnt/user/system/appdata or who have it on an unassigned device, that setting is going to wind up creating a new appdata share unless the user automatically changes it.

If people deviate from the OS defaults then that is their choice and thus their problem, it's their responsibility to adjust things that are by default tied to the default concept because nobody can account for any possible configuration.

 

4 hours ago, Squid said:

Shouldn't the OS automatically adjust the settings to match what the USER has specified?

I'm all for consistency, either you patch things in a way that always reliably makes sure things are good (which is essentially impossible) or you do nothing (but educate the user as to why things work this way). If something "goes wrong" then knowing about it as soon as possible is paramount, without patching someone would lose their data within a week and look for the reason while still manageable, with unclear patching that may hide issues on a specific service and a dangerous situation can linger for months/years where when the loss happens it's way more devastating.

 

I understand the legacy and I wasn't using Unraid 10 years ago, but still in the meantime Unraid has changed quite a bit, and as I understand back then most web services you'd want to host were not published as Docker containers by the app maintainers so most stuff in CA would have been tailored to Unraid by community members, and using /config for appdata could have easily been a convention in this environment. Nowadays pretty much every hostable service like SearxNG publishes a container so there is no reason to make one specifically for Unraid, and they will have zero knowledge that there's a NAS OS out there that expects /config for configuration data so they'll use anything they want.

 

I.e. things change and IMO while valid at the time the specific workarounds made back then that tackled the few potential issues that happened then are now outdated, there are now way more potential issues they don't cover and they are probably doing more harm than good overall as they stand. 

Edited November 21, 20241 yr by Kilrah

31 minutes ago, Kilrah said:

Agree templates that reference "cache" should be blacklisted. As mentioned by @DiscoverIt some were for performance benefits and most of them would probably be from before exclusive shares existed and are probably unmaintained if they weren't updated.

@ich777 I believe still has maintained containers that require direct disk access.

 

32 minutes ago, Kilrah said:

If people deviate from the OS defaults then that is their choice and thus their problem, it's their responsibility to adjust things that are by default tied to the default concept because nobody can account for any possible configuration.

We'll agree to disagree, especially since the automatic remapping of /config paths has been in place for a decade.  The new thing is for anything that's not /config will get remapped by CA IF the value or default in the template refers to the default appdata path as shipped.  In which case it will get changed to whatever the user has set.  Same result.

 

35 minutes ago, Kilrah said:

Nowadays pretty much every hostable service like SearxNG publishes a container so there is no reason to make one specifically for Unraid, and they will have zero knowledge that there's a NAS OS out there that expects /config for configuration data so they'll use anything they want.

And that's the exact reason why CA will adjust the paths to match the user's environment.

 

It's a rare occurrence where a template exists within Apps that is passed unchanged for one reason or another to dockerMan.  And that is part of the success story of both CA and Unraid.  Things get adjusted to suit.  

8 hours ago, Kilrah said:

Agree templates that reference "cache" should be blacklisted.

12 hours ago, DiscoverIt said:

Any developer doing a commit to make the template default to /mnt/cache or similar should be flagged for blacklisting.

8 hours ago, Squid said:

@ich777 I believe still has maintained containers that require direct disk access.

Okay, then probably only a hand full of applications will be left in the CA App from me...

 

I think I also installed a container only for testing from Linuxserver or from Binhex which uses also the cache path.

 

The reason why I started using /mnt/cache/... was because some dedicated servers would simply Segfault when using /mnt/user/...

This is just a short list and only a few that I remember:

• Garry's Mod
• TeamFortress 2
• PVK II
• ...

Mostly Source Engine powered dedicated servers IIRC (I can't quiete remember which games exactly).

 

EDIT: I've now tried it, Garry's Mod and PVK II are working with exclusive shares and /mnt/user/... however if not using exclusive shares then usage from /mnt/user/... will result in a crash loop from the dedicated server.

 

 

8 hours ago, Squid said:

And that's the exact reason why CA will adjust the paths to match the user's environment.

Do you know by any chance to what the appdata share is set by default? Is it set to move the data from the Cache to the Array? Could this be maybe changed if that is the case?

 

8 hours ago, Kilrah said:

before exclusive shares existed

I have to admit that I haven't tried one of the above listed dedicated servers with an exclusive share, however even if it will work is exclusive shares on by default?

 

 

EDIT2: I'm open to change all my templates to /mnt/user/...

9 hours ago, Squid said:

@ich777 I believe still has maintained containers that require direct disk access.

Obviously exceptions would be allowed when required, but in most cases it isn't

 

9 hours ago, Squid said:

We'll agree to disagree, especially since the automatic remapping of /config paths has been in place for a decade.  The new thing is for anything that's not /config will get remapped by CA IF the value or default in the template refers to the default appdata path as shipped.  In which case it will get changed to whatever the user has set.  Same result.

My point is that a better solution would be a dedicated "<AppdataPath>" tag in the templates, that one gets adjusted to the user's appdata path config and others not resulting in a clear behavior and intent instead of trying to take "obscure" guesses with neither the users or template creators really knowing/understanding what happens.

after the update i'm still getting /mnt/poolname instead of /mnt/user
to be fair it happens system wide not respecting set paths for example in vms i have settings > vm manager using /mnt/user yet it defaults to /mnt/poolname also when making a vm, if im not using exclusive share then it sets it correctly.

Edited November 22, 20241 yr by jcofer555
added info

5 hours ago, ich777 said:

Do you know by any chance to what the appdata share is set by default?

/mnt/user/appdata/

 

2 hours ago, Kilrah said:

My point is that a better solution would be a dedicated "<AppdataPath>" tag in the templates, that one gets adjusted to the user's appdata path config and others not resulting in a clear behavior and intent instead of trying to take "obscure" guesses with neither the users or template creators really knowing/understanding what happens.

But isn't that really what we are doing with /config?  And nothing is "obscure" if something other than /config refers to /mnt/user/appdata/.  That path gets changed to whatever is set as the user's appdata path.  Nothing else.  There's no guessing involved...

13 minutes ago, Squid said:

/mnt/user/appdata/

Sorry I meant if it is set to stay on Cache or moved to the Array, but I assume it's set to be moved to the Array.

6 hours ago, ich777 said:

Okay, then probably only a hand full of applications will be left in the CA App from me...

 

I think I also installed a container only for testing from Linuxserver or from Binhex which uses also the cache path.

 

The reason why I started using /mnt/cache/... was because some dedicated servers would simply Segfault when using /mnt/user/...

This is just a short list and only a few that I remember:

• Garry's Mod
• TeamFortress 2
• PVK II
• ...

Mostly Source Engine powered dedicated servers IIRC (I can't quiete remember which games exactly).

 

EDIT: I've now tried it, Garry's Mod and PVK II are working with exclusive shares and /mnt/user/... however if not using exclusive shares then usage from /mnt/user/... will result in a crash loop from the dedicated server.

 

 

Do you know by any chance to what the appdata share is set by default? Is it set to move the data from the Cache to the Array? Could this be maybe changed if that is the case?

 

I have to admit that I haven't tried one of the above listed dedicated servers with an exclusive share, however even if it will work is exclusive shares on by default?

 

 

EDIT2: I'm open to change all my templates to /mnt/user/...

 

Exclusive share is the way to go. While its not enabled by default it can be enabled if a user has a share which solely resides on a non-unraid pool. This could be addressed with a notation in the description or tool tip for the required containers. IIRC I've seen others (maybe a SQL template?) indicate exclusive shares should be used for performance and reliability purposes. I cannot speak for segfaults in a default /mnt/user configuration and while a stretch maybe there is some need in a feature request to have a hidden/advanced field for "Requires Exclusive Access Share", dunno.

 

My main beef with /mnt/cache as default is it relies on an educated user when the UnRaid user pool is often on the other end of linux/nas/server knowledge spectrum. Many instances have occurred where the user specifies /mnt/cache because SpaceInvader once did a video on it years ago but then fail to correlate that a running mover breaks their setup. The data isn't gone but since the service is only looking in /mnt/cache it fails to see the majority of share data (<v7) is now residing in /mnt/user0.

2 minutes ago, DiscoverIt said:

Exclusive share is the way to go.

TBH I don't see a reason to enable it on my system.

 

5 minutes ago, DiscoverIt said:

I cannot speak for segfaults in a default /mnt/user configuration

I had many issues in the past with that and that's why I use it almost in all of my templates.
 

7 minutes ago, DiscoverIt said:

My main beef with /mnt/cache as default is it relies on an educated user when the UnRaid user pool is often on the other end of linux/nas/server knowledge spectrum. Many instances have occurred where the user specifies /mnt/cache because SpaceInvader once did a video on it years ago but then fail to correlate that a running mover breaks their setup.

I agree on that because I have to explain this from time to time in my game servers thread but after explaining it to users once it is most of the times solved.

Most users or new users move appdata to the Array (unknowingly what they are doing most of the times) which in my book makes not much sense because containers should have their data an fast storage anyways.

24 minutes ago, ich777 said:

TBH I don't see a reason to enable it on my system.

 

I had many issues in the past with that and that's why I use it almost in all of my templates.
 

I agree on that because I have to explain this from time to time in my game servers thread but after explaining it to users once it is most of the times solved.

Most users or new users move appdata to the Array (unknowingly what they are doing most of the times) which in my book makes not much sense because containers should have their data an fast storage anyways.

I'm curious on your stance with you being frankly a key pillar in this eco system. Why are you against exclusive access shares if a share such as appdata resides solely on say cache? The setting (which imo should be default if the share meets certain settings) makes an opaque layer of the system transparent with nearly no downside to the end user. Imo the only rationale I can find is that you cannot create an NFS export of an exclusive share without some side hackery.

9 minutes ago, DiscoverIt said:

I'm curious on your stance with you being frankly a key pillar in this eco system.

Thanks for that but I don‘t see me as a pillar at all…

 

10 minutes ago, DiscoverIt said:

Why are you against exclusive access shares if a share such as appdata resides solely on say cache?

I‘ve never said I‘m against it, I don‘t see a reason why I should switch over on my main server.

45 minutes ago, ich777 said:

I‘ve never said I‘m against it, I don‘t see a reason why I should switch over on my main server.

If you just access data locally on UNRAID (with dockers and so on), exclusive shares do not do anything.

They come handy if you access them over LAN, by eliminating the FUSE overhead, speed can go up by 100% on 10G LANs when used with NVMe drives.

But again, makes no difference if it just locally.

Maybe even a unmeasurable bit slower because of the symlink.

 

3 minutes ago, MAM59 said:

If you just access data locally on UNRAID (with dockers and so on), exclusive shares do not do anything.

That's very incorrect, going through FUSE is the same local or remote and can have massive impact on some containers.

Edited November 22, 20241 yr by Kilrah

2 minutes ago, Kilrah said:

is the same local or remote and can have massive impact on some containers.

hmm... maybe you are right, but I dont see any impact here. Maybe fooled by caches ?

 

good day I have been using unraid for 3 or so years and this is the first time i have rain into this im running unraid latest 40 gig ram 27 tb hard drive Xeon ,WD hard drives 1 gig internet speed not sure what else to put but i cannot install the updated community apps and now have no access to my CA section and it says to install and when I do this is what I get back 

 

plugin: installing: community.applications.plg Executing hook script: pre_plugin_checks plugin: downloading: community.applications.plg ... done Executing hook script: pre_plugin_checks Cleaning Up Old Versions Fixing pinned apps Setting up cron for background notifications plugin: downloading: community.applications-2024.11.29-x86_64-1.txz ... plugin: community.applications-2024.11.29-x86_64-1.txz download failure: Generic error Executing hook script: post_plugin_checks  any help would be great