• Not possible to disable User Share cache mode if no cache pool is present


    mgutt
    • Minor

    This user had the problem that one of his containers (probably) created the path /mnt/cache although he had no cache pool and by that it was not possible to disable the caching:

    image.png.ba916db50445e26d7e900cdb6b5bd581.png

     

    And as default cache setting of the appdata share is "Prefer" all Containers installed their files into this path, which flooded his RAM:

    root@Tower:~# du -sh /mnt/cache
    2.3G    /mnt/cache

     

    ls -la /mnt/cache/appdata
    total 0
    drwxrwxrwx 8 nobody users 160 Apr  8 20:52 ./
    drwxr-xr-x 4 root   root   80 Apr  9 04:40 ../
    drw-rw-rw- 7 root   root  220 Apr  8 19:43 MQTT/
    drwxrwxr-x 4 nobody users 120 Apr  8 20:07 binhex-krusader/
    drwxr-xr-x 4 nobody users 100 Apr  8 20:52 mariadb/
    drwxr-xr-x 8 nobody users 180 Apr  8 21:18 nextcloud/
    drwxrwxrwx 7 root   root  140 Apr  8 18:41 onlyofficeds/
    drwxr-xr-x 4 root   root   80 Apr  8 18:38 pihole/

     

    image.png.2bb0f8435e210e9cc9ecb987173b6cdc.png

     

    Proposal:

    It should be possible to disable the caching even if no cache pool is present. Or nothing should be able to create the /mnt/cache path as long no cache pool is present.




    User Feedback

    Recommended Comments

    docker itself automatically creates every host path, and probably not much the devs can do about it.

     

    But, since /mnt/user0 now exists all the time regardless if a cache pool is present or not, maybe mover can check if the pool is present before moving anything to it.  (Although thinking about it, I can see some interesting use cases for not having a defined cache-pool but having the extra mount point within /mnt)

    Link to comment
    2 hours ago, Squid said:

    docker itself automatically creates every host path, and probably not much the devs can do about it.

     

    Yep, docker creates whatever it is presented, good or bad. Consequently any wrong paths end up in RAM.

     

    Link to comment

    As an aside, CA looks for hard-coded paths (to pools or disk shares) and automatically adjusts the templates to suit the user's system (so that it doesn't cause issues like this)

    Link to comment
    7 hours ago, Squid said:

    so that it doesn't cause issues like this

    Is this a "new" feature? Maybe the user had installed a container in the past with a /mnt/cache path and by that the template was already part of his "previous apps" (which bypasses the auto adjustment of CA). The user said he never had a cache pool and this problem occurred not until upgrading to Unraid 6.9.

     

    Finally I suggested the user to edit the /shares/sharename.cfg and disable the cache through the "shareUseCache" variable.

    Link to comment
    On 4/9/2021 at 9:15 PM, mgutt said:

    Is this a "new" feature?

    2020.04.19
    Fixed: Display aberration after installing a single app from Previous Apps
    Added: If an app directly references a disk or cache pool in the template, adjust template accordingly if the user does not have the disk / cache pool installed
    Fixed: If installing an app from a search immediately after starting CA, the start up category would remain highlighted when returning back to CA after the install

     

    Only on new installs.  CA does not do anything with previous apps

    Link to comment

    as @mgutt has mentioned, i have never used the Cache Pool.

     

    After Upgrade from 6.8.x to 6.9.0 and then 6.9.1 I have problems with the increasing of rootfs partition. 

    because the docker instances used /mnt/cache for appdata

    Link to comment
    7 hours ago, dimon said:

    as @mgutt has mentioned, i have never used the Cache Pool.

     

    After Upgrade from 6.8.x to 6.9.0 and then 6.9.1 I have problems with the increasing of rootfs partition. 

    because the docker instances used /mnt/cache for appdata

    If you do not have a cache drive then you need to reconfigure them to not use ‘mnt/cache’.   I do not see how that could have worked on any unRaid release with no cache drive present as if you do not have a cache drive that location is in RAM.   In such a case you should use /mnt/user/appdata as that allows files to be on either the array or a cache drive.

    Link to comment

    If /mnt/cache exists via a container making it, the mover will attempt to move into it.  The solution is to properly configure the container.

     

    The reason for the change in behaviour from 6.8 to 6.9 is because now /mnt/user0 always exists.

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.