• Changing the appdata share name on the cache pool takes over and renames appdata on the secondary pool


    SimplifyAndAddCoffee
    • Closed

    Here's what  I did

     

    1. create new pool, name it docker
    2. add single disk to new pool
    3. unpack the contents of my old docker unassigned device disk to the new docker pool. The volume contains a directory named 'appdata'
    4. try to share the pool in shares. Select cache:only and select pool:docker, name the share data
    5. try to go to \\server\data, find the folder empty
    6. go to console, and see that it has created a new directory, 'data' in /mnt/docker/ and shared that.
    7. I need to share the 'appdata' folder in the docker volume, so I rename the 'appdata' share that I'm not using for apps (cache:preferred, pool:cache) to 'appcache', and rename the 'app' share to 'appdata'
    8. All my dockers break
    9. look in \\server\appdata share, and see that it is empty!
    10. In the console, see that /mnt/docker/ now has an 'appcache' directory that contains all of the files that used to be in the 'appdata' directory. 
    11. check on the 'appcache' share, and see that it is still using pool:cache? change it to cache:only, but it still is connected to the data on the docker pool
    12. rename 'appdata' to 'appdata2' and 'appcache' to 'appdata'. Now the data is back in the /mnt/docker/appdata directory where it belongs, but I can't unlink it from the 'appdata' share, and I can't link a new share to it
    13. even after restarting the docker service and all my dockers, I can no longer access any of them from my browser, despite seeing no changes in the config

     

    How boned am I?

    mewcaster-diagnostics-20210209-1915.zip




    User Feedback

    Recommended Comments

    I don't think you're "boned" at all. Your files are all still where you put them, they are just lost in the confusion of all the renaming.

     

    It's obvious from what you wrote that you're not clear quite how user shares work and how multiple pools operate. So let's go through each step.

     

    Steps 1 to 3. Ok, everything is as expected.

     

    In Step 4, you create a new share called "data" with the settings cache:only and pool:docker. What that does is to create a new empty directory in the root of the "docker" pool. That's what a new user share is - an empty directory in the root of one of your data disks or pools. Your files are still there, in the directory called "appdata".

     

    Step 5, therefore, is as expected.

     

    Step 6, is as expected and explained in Step 4, above.

     

    Step 7 is confusing because you mention the renaming of a share called "app" to "appdata". That's the first time you mentioned  the "app" share, so I don't know what it contains. You say you need to share the "appdata" folder, but you're already doing that by the fact that, in Step 3, you say that the new "docker" pool contains a directory called "appdata".

     

    Step 8, is not surprising because you renamed your "appdata" share to "appcache" in Step 7 and renamed the "app" share to "appdata". So your containers are now expecting to find their files in the directory that was previously called "app", whose contents (to me, at least) are unknown.

     

    In Step 9 you discover that the "appdata" share is empty. That implies that the previously named "app" share was empty. At this point, the files you want are safe inside the "appcache" share.

     

    Step 10. As expected and explained above.

     

    Step 11. Changing the name of a share doesn't move data. It just changes the name of the folder where it exists in the root of each disk and pool.

     

    Step 12. More renaming. The "appdata2" share now contains what the "app" share originally contained - nothing. The "appdata" share is back as it was.

     

    You can't unlink the "/mnt/docker/appdata" directory from the "appdata" share because the "appdata" share is a union of the following directories, some of which may not be present and some of which may be present but empty:

    • /mnt/cache/appdata
    • /mnt/docker/appdata
    • /mnt/any-other-pool/appdata
    • /mnt/disk1/appdata
    • /mnt/disk2/appdata
    • /mnt/diskN/appdata

    If you rename the "appdata" share, as you did, to "appcache", then all these root level directories that exist get renamed.

     

    So, after all the renaming your appdata files are still where you originally put them, in the /mnt/docker/appdata directory and, by definition of what a user share is, in the "appdata" user share. You just need to do a couple of things:

     

    1. Reconfigure each of your docker templates so that they map to /mnt/user/appdata (or /mnt/docker/appdata, if you wish) instead of to the location on your unassigned device tha you previously used (which was probably something like /mnt/disks/unassigned-disk-name/appdata).
    2. Tidy up. On the Shares page of the GUI click the "Compute All" button and look at the row corresponding to the "appdata" share. It will show you which disks and pools are involved. Keep the "appdata" directory on the "docker" pool but delete the ones on other disks/pools - obviously check their contents first to make sure they are either empty or that any files are duplicates of the ones on the "docker" pool. You'll want to remove the spurious empty "data" and "appdata2" shares that you created too, but again, make sure you didn't accidentally save anything you want to keep in them. It might be worth creating a temporary user share and moving anything you're not sure about into it and later deleting it at your leisure.

     

    So, not a bug at all.

     

    Link to comment
    On 2/9/2021 at 10:22 PM, John_M said:

    Changing the name of a share doesn't move data. It just changes the name of the folder where it exists in the root of each disk and pool.

    ok I'm gonna nitpick here and say that's moving it. Functionally the data has moved and is no longer at the path where applications are looking for it.

     

    On 2/9/2021 at 10:22 PM, John_M said:

    You can't unlink the "/mnt/docker/appdata" directory from the "appdata" share because the "appdata" share is a union of the following directories, some of which may not be present and some of which may be present but empty:

    • /mnt/cache/appdata
    • /mnt/docker/appdata
    • /mnt/any-other-pool/appdata
    • /mnt/disk1/appdata
    • /mnt/disk2/appdata
    • /mnt/diskN/appdata

    What... the fuck? why? appdata is or should be by its nature assigned a static path by the applications that use it. You don't want appdata on the array, and with this arrangement, how do you even control where it goes if you actually point something at the share? This seems like a really poor design choice from the perspective of safe data storage. 

     

    It explains perfectly why I had this issue and why I was confounded by it: doing it that way seems insane to me so it never crossed my mind.

     

    Sorry, that's just frustrating.

     

    On 2/9/2021 at 10:22 PM, John_M said:

    Reconfigure each of your docker templates so that they map to /mnt/user/appdata (or /mnt/docker/appdata, if you wish) instead of to the location on your unassigned device tha you previously used (which was probably something like /mnt/disks/unassigned-disk-name/appdata).

    OK Again I still don't understand why you would ever want to point them to the share if you can't effectively control what device pool the data ends up on. The UI intuitively makes it sound as if the data will go to the pool location you specify, but I'm not entirely convinced that's the case. Can I trust it to do that? I explicitly want the data to exist on the docker pool and only on the docker pool. That is where my apps are already pointing at this point, and it's where I need SMB access to pull/put files such as for nginx. 

     

    So this brings me to a new question of, is there no way to share an existing directory in unraid? will I fuck something up if I try to call samba directly to do it? I would, for example, really like to make a share mapping to a directory that already exists and is full of files I want to access without moving them. e.g. /mnt/docker/appdata/nginx/html/www/ so that I can give someone access to tamper with the website without giving them access to the whole drive.

    Link to comment

    For a long time there was only one pool and it was called "cache". The ability to have multiple pools was only added in the beta phase of 6.9. I've explained how it is, but I'm not going to argue about why. To understand it better you might find this article useful:

     

     

    It was written before multiple pools were possible. The concept of the cache pool was extended to allow for multiple pools. You can cache files being written to a given user share in any one of the pools you have available. Traditionally there was only one and it was called "cache". Now it can be called something else. Additionally, a pool doesn't have to be used exclusively, or even partially for caching. In fact, the typical use for a pool (even the one called "cache") is to store application data for Docker containers and virtual disk images for VMs. The terminology currently in use could probably be improved.

     

    You can move files from a pool to the array and from the array to a pool (the same or different - you can choose) by careful use of the "Cache:" and "Pool:" options and running the Mover.

     

     

    Edited by John_M
    Typo
    • Like 1
    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.