Cache vs User Appdata path

[ich777]

Hello,

 

can somebody explain me the /mnt/cache/appdata/... and /mnt/user/appdata/... thing?

Some of my containers not working on the array or better speaking since Unraid version 6.8.0 so i changed most of my containers to the path /mnt/cache/appdata/... now with Unraid version 6.8.3 i have to change some paths back to /mnt/user/appdata/...

Otherwise some containers can't acces or even read the files (Don't Starve is such an example or Garry's Mod.

On other main problem is here if you haven't a cache drive installed then the data there is not persistant.

 

Regards,

Christoph

[itimpi]

1 hour ago, ich777 said:

Hello,

 

can somebody explain me the /mnt/cache/appdata/... and /mnt/user/appdata/... thing?

Some of my containers not working on the array or better speaking since Unraid version 6.8.0 so i changed most of my containers to the path /mnt/cache/appdata/... now with Unraid version 6.8.3 i have to change some paths back to /mnt/user/appdata/...

Otherwise some containers can't acces or even read the files (Don't Starve is such an example or Garry's Mod.

On other main problem is here if you haven't a cache drive installed then the data there is not persistant.

 

Regards,

Christoph

This is the case where one refers to a physical drive, and the other to a logical view that can (potentially) span multiple drives.   Mapping to a physical drive can improve performance as it removes the overhead of accesses via the User Share sub-system.

 

/mnt/cache/appdata is meant to refer to the 'appdata' folder on the physical cache device(s).

/mnt/user/appdata refers to the logical view provided by the User Share sub-system and will include the contents of any 'appdata' folders found on any array drive or the cache drive. 

 

You must NOT attempt to map anything to /mnt/cache if you do not actually have a cache  as in such a case that location is purely in RAM and not persistent across reboots.

 

In simplistic terms anything directly under /mnt/cache or /mnt/diskX is a physical device and those under /mnt/user are logical views of the data on the physical devices.

 

[ich777]

@itimpi Thanks for the explanation.

 

But can you also tell my why some of the container work with the path /mnt/user/appdata/... and some only work with the path /mnt/cache/appdata/... has this eventually something to do with the filesystem and how Unraid handles the containers?

 

The problem only exists as of the Unraid version 6.8.0 if you have an earlier version installed all containers work with the path /mnt/user/appdata/... (It takes me a few posts on the forum to figure it out that i have to change the path to /mnt/cache/appdata/...).

 

See this post:

 

[itimpi]

29 minutes ago, ich777 said:

@itimpi Thanks for the explanation.

 

But can you also tell my why some of the container work with the path /mnt/user/appdata/... and some only work with the path /mnt/cache/appdata/... has this eventually something to do with the filesystem and how Unraid handles the containers?

 

The problem only exists as of the Unraid version 6.8.0 if you have an earlier version installed all containers work with the path /mnt/user/appdata/... (It takes me a few posts on the forum to figure it out that i have to change the path to /mnt/cache/appdata/...).

 

See this post:

 

Not sure, but I suspect that you have some of the file/folders for the appdata share on an array drive so they are not seen when you use the /mnt/cache/appdata path but are seen when using /mnt/user/appdata.    There are some other more obscure possibilities but that is the most likely.     If you posted your diagostics zip file (obtained via Tools >> Diagnostics) we could see if that is the case.

[ich777]

10 minutes ago, itimpi said:

Not sure, but I suspect that you have some of the file/folders for the appdata share on an array drive so they are not seen when you use the /mnt/cache/appdata path but are seen when using /mnt/user/appdata.    There are some other more obscure possibilities but that is the most likely.     If you posted your diagostics zip file (obtained via Tools >> Diagnostics) we could see if that is the case.

No, i can definitely tell you that this is not the case (also that is the other way around that you described and the problem was introduced in 6.8.0).

 

Also this is not only a problem on my specific server that problems are reported by users that are using my containers (especially Don't Starve, Garry's Mod and a few others)...

[itimpi]

If you have containers that only work with /mnt/cache then it probably means that they are using hard links at the Linux level and the handling of those has always been problematical under the /mnt/user path.   However why that should have changed recently I have no idea.   it could also have something to do with the way that Docker handles these as it is quite likely to have changed in recent Docker releases.

[ich777]

@itimpi

 

Also i found this topic in my own thread please read the comment (this was/is an ongoing 'issue'):

 

[ich777]

Over the weekend i created two containers and tested them on my Unraid 6.8.3 machine, ECO and IW4x.

ECO needs the path /mnt/user/... and IW4x needs the path /mnt/cache/... also one user found out that Quake3 is also only working with /mnt/cache/...

 

What do people that don't have a cache drive installed (i think this will be not much but there are a few out).

[Squid]

6 hours ago, ich777 said:

What do people that don't have a cache drive installed (i think this will be not much but there are a few out).

They would direct the appdata share for those affected apps to be /mnt/diskX/appdata/...

 

On 3/18/2020 at 11:01 AM, itimpi said:

If you have containers that only work with /mnt/cache then it probably means that they are using hard links at the Linux level and the handling of those has always been problematical under the /mnt/user path.   However why that should have changed recently I have no idea.

 

On 3/18/2020 at 10:35 AM, ich777 said:

problem was introduced in 6.8.0)

Without really diving into all of the release notes and comments scattered throughout, under global share settings is a Use Hard Links option.  This IIRC was added in (according to the help text) to improve compatibility with NFS, but I believe that the option also affects how the inode numbers are handled on hardlinked files.

 

On 3/18/2020 at 9:42 AM, ich777 said:

But can you also tell my why some of the container work with the path /mnt/user/appdata/... and some only work with the path /mnt/cache/appdata/... has this eventually something to do with the filesystem and how Unraid handles the containers?

As itimpi alluded to, this has been an ongoing issue for some containers and some users.  You will see the occasional comment scattered throughout the threads with the advice being given to a user to switch to /mnt/cache/appdata.

 

The trouble however is that for other users leaving things at /mnt/user works no problems.  

 

And, despite some occasional posts from myself to the docker authors to the effect of "OK, fine what is the actual problem", no one has thus far been able to point a finger at "this is why its failing"  If anyone could ever outright point out why /mnt/user fails for some but works for others, then I'm sure Limetech would fix the issue.

 

 

The advice I'm offering you, since you've already diagnosed that the app wants /mnt/cache, is to see whether or not it works as /mnt/diskX  If it does, then basically you're good to go.  If it doesn't, then you've got to get together with Limetech and figure out what's going on.