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

    • Annoyance


    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:


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


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


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


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



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


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



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


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



    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/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.

    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...