Jump to content
  • [6.12.4] Apps templates resolve exlusive appdata share to pool


    RiffSphere
    • Annoyance

    Hi,

    Not sure if this is unraid or community apps, but since it's now so closely integrated with a single button install, I'm going to post this here. Please move if needed.

     

    On a new server, I created an "appdatapool" pool:

    https://imgur.com/8eDRjBk

    Next, I made the appdata share an exclusive share with just that pool:

    https://imgur.com/ByPW7Yp

    My docker is configured to use /mnt/user/appdata as default appdata storage:

    https://imgur.com/oWTlntH

    Some containers, like IBRACORP's jellyseerr, seem to use the /mnt/user/appdata share correctly:

    https://imgur.com/6Vqbq34

    However, it seems they just have it hardcoded in their template:

    https://imgur.com/undefined

     

    Other containers, like linuxserver's sonarr, will follow the symlink (according to the docs, exclusive shares are symlinks I believe?)

    https://imgur.com/Nenld06

    Checking out their template, the Appdata path has no default, and should be filled from my docker config, I believe?

    https://imgur.com/gNo55wP

     

    Now, if I make the share not an exclusive share:

    https://imgur.com/50aXXEc

    And I try to install linuxserver's sonarr again, it does take my configured appdata share:

    https://imgur.com/jfR2Kao

     

    The docs (https://docs.unraid.net/unraid-os/manual/docker-management/#appdata) suggest that the appdata share should be used ("By convention the appdata share is used for this purpose, with each container using a container specific sub-folder in this location."). When I have an exclusive share, already bypassing the FUSE system and overhead, my appdata defaults to the pool, it seems to resolve the symlink. When not having an exclusive share, and one might actually want to put the appdata directly on the pool and not the share to bypass FUSE, the share is being used correctly.

     

    I know, it's just a few click to change this, but it's easy to forget an can cause issues down the line (for example, creating a new pool for appdata while keeping the old one in place, restoring a backup and changing the appdata share to use that, suddenly your appdata will be randomly split between 2 pools).




    User Feedback

    Recommended Comments

    I'll have to look at this, but having Default set in the templates or not has absolutely no bearing on the system adjusting paths to match the default appdata share.

     

    ANY container path of /config is automatically adjusted to be /defaultAppDataPath/NameOfContainer

     

    Any other container path is never adjusted to match because the system doesn't technically know that it's the appdata path.  EG: any host path of /opt mapped to /mnt/user/appdata//... will never get adjusted.  This is part of the reasoning for the defacto naming scheme to be a share named appdata and references to /mnt/user/appdata

     

    FWIW, The apps tab also automatically adjusts templates to match your system.

     

    If it sees any path that directly references a disk (array or cache pool) and the disk doesn't exist in your system, CA will set the path to something that does exist in your system.  IE:  /mnt/cache/blah will automatically get adjusted by CA to reference whatever cache pool you have IF you don't have a pool named "cache" 

    Link to comment

    - ANY container path of /config is automatically adjusted to be /defaultAppDataPath/NameOfContainer

    That's probably why the ibracorp's jellyseer is not getting changed, it's mapped to /app/config. I just found it strange that, in my limited testing with just the containers I was installing, the issue would happen when the appdata path in the template was empty, and not if it had defaults in it. But I guess it's more related to good templates using /config (and leaving it empty) and bad templates using another path (and have a default setting)?

     

    - However, that wasn't the main part of my bug report. Following are the defaults for the same container (linuxserver sonarr), first one with exclusive share, second without exclusive share (all settings the same, just added array as secondary storage for the non exclusive share):

    https://imgur.com/Nenld06

    https://imgur.com/jfR2Kao (ignore the extra -1 at the end, I saved the config to check the template when doing the exclusive share)

    As far as I know, it shouldn't use "/mnt/appdatapool/appdata/[container] for appdata, but /mnt/user/appdata/[container]. To be clear, both do point to the same location: https://imgur.com/a/hKJ4oaI, so I think it resolves the symlink instead of using it as the path.

    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.

×
×
  • Create New...