Hello, 

 

I upgraded my cache drive just yesterday and followed the official documentation I'm doing so.... I stopped the vm and docker service, moved the data via the cache->array method, then clicked the mover. 

 

After the mover completed. ( I did stop the mover, and resume it a couple of times because I didn't know what I was doing) I moved the data back to my new installed cache drives, via the arry->cache method .( after I formatted and created a new pool for them) all the data and drives look about correct. 

 

But the issue I am having now is after enabling docker again, is none of my docker containers can find the settings for them.

I can't login to any containers that require them, ( ngix for example) containers such as emby and nextcloud want me to setup the docker as a new install, and I'm having permission issues with postgres for example. 

 

I assume the issue is where my appdata share folder is, (it's on my cache drive I think, but I also have a folder with it on the array I think as well), but when I attempt to change the template for my docker containers from /mnt/user/whatever docker container.

..to /mnt/cache/whatever docker container, I still have the same issue, where my docker containers are acting like new installs, when I can see that there is data in my shares.

 

I'm lost how to correct this issue, any help please?

tower-diagnostics-20250429-0933.zip

https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file

 

https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications

 

https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

Thanks for the info, I will attempt to delete the docker image and recreate it. Along with my custom networks and report back with results.

@trurl So, to give an update your solution worked, I would have never guessed these was the additional steps I needed to take to get my containers back...

 

But I now have one small issue. Now I have duplicate appdata folders and locations. How do you recommend I delete the duplicate data without harming my NEEDED appdata folder location?

 

Currently my dockers only retain information if it's in /mnt/cache/appdata/appdata/whatever docker.

But currently I also have /mnt/cache/appdata whatever docker.

 

Also I have a /mnt/user/appdata location as well, do I really need this?

 

See attached screenshot.

Post new diagnostics

It shouldn't really matter if one is /mnt/cache/appdata or /mnt/user/appdata as they both reference the same place. (just a different way to get there)

 

You might have something that's accidentally set to /mnt/user/appdata/appdata/EmbyServer so you need to double check that

Edited April 30, 20251 yr by MowMdown

You can see what path each of your containers are using in its Volume Mappings on the Docker page.

3 hours ago, trurl said:

Post new diagnostics

I will post an updated diagnostics once I get home from work. 😊

 

Also let me clear up my post a bit..

 

if I point my docker containers to /mnt/cache/whatever the docker containers do not find any user settings and this is for all my containers, so I have a duplicate of everything. 

 

Only when I point containers to /mnt/cache appdata/appdata/whatever then my containers pull in user settings. I just referenced emby here as an example.

 

I need to figure out how to delete the duplicate data, it's making configuration confusing for me...

You must have tried to reinstall without using Previous Apps, before I posted the links about that. So it created new appdata using the default template for the container instead of the templates you had saved.

 

If you think your appdata is really in /mnt/cache/appdata/appdata (why?) then you could just change the mapping to go there instead of the (more normal) /mnt/cache/appdata.

 

Or better, just copy /mnt/cache/appdata/appdata to /mnt/cache/appdata.

 

Not that hard to figure out and not that hard to do. Just takes some attention to detail.

43 minutes ago, trurl said:

You must have tried to reinstall without using Previous Apps, before I posted the links about that. So it created new appdata using the default template for the container instead of the templates you had saved.

 

If you think your appdata is really in /mnt/cache/appdata/appdata (why?) then you could just change the mapping to go there instead of the (more normal) /mnt/cache/appdata.

 

Or better, just copy /mnt/cache/appdata/appdata to /mnt/cache/appdata.

 

Not that hard to figure out and not that hard to do. Just takes some attention to detail.

I reinstalled using the Previous Apps as you suggested.....

 

Also I noticed one of my docker containers has user settings in /mnt/cache/appdata while the rest of my containers have a location of /mnt/cache/appdata/appdata. Would you recommend I just verify container by container where the settings truly live, and just delete the rest? I just dont want to make another mistake i cant fix is all..

 

And another diagnostics is attached.

 

Thanks for your help

tower-diagnostics-20250430-2010.zip

Diagnostics don't really tell us much about your individual containers.

 

I can see that appdata has some files on disk1 though. If you have specified /mnt/cache/appdata for all of your containers, then the appdata on disk1 will not be used. It would only be used if you specified /mnt/user/appdata.

 

11 hours ago, Mrtj18 said:

Would you recommend I just verify container by container where the settings truly live, and just delete the rest?

You could do that.

 

Personally, I would clean that all up by getting rid of that extra appdata/ in the path and moving those up a level.

 

Looks like you probably have a lost+found share on disk1, from a previous filesystem repair. Have you examined those?

Apr 30 17:44:00 Tower root: Fix Common Problems: Warning: Share access is an implied array-only share, but files / folders exist on the cache
Apr 30 17:44:00 Tower root: Fix Common Problems: Warning: Share custom_ssl is an implied array-only share, but files / folders exist on the cache
Apr 30 17:44:00 Tower root: Fix Common Problems: Warning: Share letsencrypt-acme-challenge is an implied array-only share, but files / folders exist on the cache
Apr 30 17:44:00 Tower root: Fix Common Problems: Warning: Share logs is an implied array-only share, but files / folders exist on the cache
Apr 30 17:44:00 Tower root: Fix Common Problems: Warning: Share nginx is an implied array-only share, but files / folders exist on the cache
Apr 30 17:44:00 Tower root: Fix Common Problems: Warning: Plugin compose.manager.plg is not up to date
Apr 30 17:44:09 Tower root: Fix Common Problems: Error: Reserved user share user ** Ignored

You should also fix those.

My advice on Fix Common Problems is to fix everything unless you can explain why you intend to have it that way, then you can tell it to ignore.

Thank you for all your help, I didn't have the errors you see now until I attempted the upgrade of my cache drive. I will attempt to solve each error a step at a time. If I have difficulty or can't figure it out, I will just have to contact paid support to get assistance. 

 

This could be over my skill level to fix correctly. 

 

Thank you

Probably we can help you for free on the forum. All of those FCP warnings are easily fixed, for example.

 

Just set each of those shares to

Primary:cache; Secondary:array; Mover action:cache->array.

 

Then run mover, wait for it to complete. After all those files have been moved from cache, you can set those to not use cache if you want.

 

And you should rename that user share named 'user'.

 

As for your appdata, we can work through that too. Maybe an example or two will get you started. How many containers do you have?

15 hours ago, trurl said:

 

As for your appdata, we can work through that too. Maybe an example or two will get you started. How many containers do you have?

I actually have 32 docker containers

 

And I think I fixed my user share issue ( deleted the folder nothing was in it) and fixed my shares having data on both the array and cache. See diagnostics attached....

 

So how do you think it's best to tackle the duplicate appdata issue?

tower-diagnostics-20250502-0616.zip

3 hours ago, Mrtj18 said:

And I think I fixed my user share issue ( deleted the folder nothing was in it) and fixed my shares having data on both the array and cache.

FCP has

May  2 06:14:28 Tower root: Fix Common Problems: Warning: Share appdata set to cache-only, but files / folders exist on the array
May  2 06:14:35 Tower root: Fix Common Problems: Error: Reserved user share user

That share named 'user' is on cache

3 hours ago, Mrtj18 said:

I actually have 32 docker containers

....

So how do you think it's best to tackle the duplicate appdata issue?

Are they all working like you want now?

On 5/2/2025 at 11:12 AM, trurl said:

FCP has

May  2 06:14:28 Tower root: Fix Common Problems: Warning: Share appdata set to cache-only, but files / folders exist on the array
May  2 06:14:35 Tower root: Fix Common Problems: Error: Reserved user share user

That share named 'user' is on cache

Are they all working like you want now?

So with the user share issue currently--- when i use the mover, and stop docker and vms, and it completes, I dont see that error anymore.

But, once I start vms and docker again and check the FCP, it let me know the error you just refrenced above. But it also mentions in the notes section . "Note that there are some valid use cases for a set up like this."--- is this okay?

 

not all my docker containers are working correctly such as:

deluge not letting me login when im using the correct password

Nextcloud constantly giving me 502 errors

And Authiela refusing to start

 

All of these was working correctly before the upgrade

7 hours ago, Mrtj18 said:

But, once I start vms and docker again and check the FCP, it let me know the error you just refrenced above.

Probably you have a docker with volume mappings to /mnt/user/user or something like that, and it is creating the user share named 'user'.

 

7 hours ago, Mrtj18 said:

"Note that there are some valid use cases for a set up like this."

If you can't explain your valid use case then you don't have a valid use case.

If you mean mover has moved all of appdata to cache, then somehow appdata gets files back on the array then you probably have a container volume specifying a disk (it is on disk1 according to diagnostics).

 

Did you set this system up yourself?

 

Do you understand docker volume mapping?

5 hours ago, trurl said:

If you mean mover has moved all of appdata to cache, then somehow appdata gets files back on the array then you probably have a container volume specifying a disk (it is on disk1 according to diagnostics).

 

Did you set this system up yourself?

 

Do you understand docker volume mapping?

1.  Yeah i kinda figured this was the issue.... Because all the data does get moved to the cache drive when vms and docker is stopped. But once I enable all services again ( docker and vm service) data ends up back on the array.

 

2. Yes I set this system up myself mainly from youtube and reading around the unraid forums.

 

3. I understand it to the extent of setting up docker containers, but if I run into problems outside of checking the logs I can get lost. which is kinda where I am today lol

4 minutes ago, Mrtj18 said:

I understand it to the extent of setting up docker containers

That is the only understanding I mean.

 

So, as mentioned,

On 4/30/2025 at 12:58 PM, trurl said:

You can see what path each of your containers are using in its Volume Mappings on the Docker page.

Make sure you click the down arrow that might appear for some in the Volume Mappings column to expand that information. It will show you all of the mappings. That is where you will probably find the answer to all of these things.

Thank you!