They would direct the appdata share for those affected apps to be /mnt/diskX/appdata/...
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.
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.