Good day all,

 

Yesterday, I decided to get rid of my cache drive as it kept getting full after couple of days so I moved back to my pool appdata.

 

Before doing that I moved all my data from my /mnt/cache/appdata to /mnt/disk9/appdataNEW. 

I used the following command (I was already in the cache appdata folder):

 

rsync -aAX --progress . /mnt/disk9

 

Once the transfer was complete I stopped the array and removed the cache drive from the array.  I started the array again went to /mnt/user and renamed the old appdata to appdata.old and renamed the appdataNEW to appdata.

 

I stopped docker and changed the appdata path and started docker again. 

 

Now the problem is that none of the dockers seem to recognize any of the saved data. Any docker container that I visit is asking me to set everything up again. The only exception is Overseer and that one has my logins saved (Plex, Radarr, Sonarr) but all request data is gone.

 

Radarr and Sonarr both want me to set everything up again. 

 

I'd appreciate any help that I can get with this issue.

 

Thanks for your time and help.

Hope you're having a better weekend than me

tower-diagnostics-20250330-1139.zip

Edited March 30, 20251 yr by whitetiger
Added the diag file

So you intend to run with everything on the array and no pools at all? Expect some performance impact from all your apps having to work with slower array reads and especially writes for their executable code and working data. And array disks won't be able to spin down since these files are always open.

 

Your diagnostics has a share anonymized as s----m

 

But, usually, diagnostics doesn't anonymize the "default" shares, so I'm wondering if you actually have a share named system.

 

I think you have the record for docker.img size. And 137G used out of the 1000G. Makes me wonder if you aren't doing some things wrong. Most containers should be configured to write data to mapped host paths in user shares, and not inside docker.img where it isn't easily accessed and will cause docker.img usage to grow.

24 minutes ago, trurl said:

So you intend to run with everything on the array and no pools at all? Expect some performance impact from all your apps having to work with slower array reads and especially writes for their executable code and working data. And array disks won't be able to spin down since these files are always open.

 

Your diagnostics has a share anonymized as s----m

 

But, usually, diagnostics doesn't anonymize the "default" shares, so I'm wondering if you actually have a share named system.

 

I think you have the record for docker.img size. And 137G used out of the 1000G. Makes me wonder if you aren't doing some things wrong. Most containers should be configured to write data to mapped host paths in user shares, and not inside docker.img where it isn't easily accessed and will cause docker.img usage to grow.

 

Thank you for replying. 

 

Are you referring to the appdata? I had no where else to move it. For whatever reason when I tried to move it to /mnt/user/ it'd still put it in the cache drive so I just chose a random drive. 

 

All docker hosts are configured to write to the appdata folder. Never touched anything with docker settings other than the appdata path.

 

 

Path for a couple of containers

 

 

I am probably doing something wrong. 

 

 

Edit:

Just looked at the appdata folder more in depth and it looks like a lot of files are missing. rsync didn't move over all files for whatever reason. 

 

Edited March 30, 20251 yr by whitetiger

17 minutes ago, whitetiger said:

Are you referring to the appdata?

I'm referring to all the "default" shares.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares

43 minutes ago, whitetiger said:

I am probably doing something wrong. 

43 minutes ago, whitetiger said:

All docker hosts are configured to write to the appdata folder.

What containers do you run?

 

Most containers have appdata for their working storage, and have other paths to allow access to other user shares for reading and writing your user data, such as media files, etc.

 

Possibly at least some of your containers are writing to paths that aren't mapped to the host user shares, and so those paths are inside docker.img,

1 hour ago, trurl said:

where it isn't easily accessed and will cause docker.img usage to grow.

And maybe others are reading and writing only appdata if you haven't mapped anything else. Instead of paths mapped to other user shares setup to hold your media and other user data.

 

1 hour ago, trurl said:

you have the record for docker.img size. And 137G used out of the 1000G.

I don't run nearly as many containers as some, just Plex and LMS, a few 'arrs, NZB and torrent apps, a few others. But default 20G docker.img has always been more than enough for my dockers.

1 minute ago, trurl said:

What containers do you run?

 

Most containers have appdata for their working storage, and have other paths to allow access to other user shares for reading and writing your user data, such as media files, etc.

 

Possibly at least some of your containers are writing to paths that aren't mapped to the host user shares, and so those paths are inside docker.img,

And maybe others are reading and writing only appdata if you haven't mapped anything else. Instead paths mapped to other user shares setup to hold your media and other user data.

 

I don't run nearly as many containers as some, just Plex and LMS, a few 'arrs, NZB and torrent apps, a few others. But default 20G docker.img has always been more than enough for my dockers.

 

Too many to list in a single forum thread lol. If I had to guess probably around 100~  But nearly every container has data pathed to appdata. I think this happened because some data is missing rsync didn't transfer all files. For example the overseer database is from 2013 for whatever reason. 

 

When I deleted my Cache drive I accidentally pressed erase so I  am trying to figure out how to recover the data to double check that everything was transferred properly. 

Just now, whitetiger said:

But nearly every container has data pathed to appdata

I expect most if not all containers to have their working data mapped to appdata. What I am questioning is whether they have anything mapped to your other users shares. Diagnostics shows you do have other user shares. Their names are anonymized so can't see their full names, but possibly something like Movies, media, etc. Do any of your containers have paths mapped to those shares? You seem to imply they don't, and only read and write appdata.

 

Post docker run for one of your containers that works with your Movies or media files.

5 minutes ago, trurl said:

I expect most if not all containers to have their working data mapped to appdata. What I am questioning is whether they have anything mapped to your other users shares. Diagnostics shows you do have other user shares. Their names are anonymized so can't see their full names, but possibly something like Movies, media, etc. Do any of your containers have paths mapped to those shares? You seem to imply they don't, and only read and write appdata.

 

Post docker run for one of your containers that works with your Movies or media files.

Oh I see, sorry. Only 1 for LanCache. But those files are not that important they can be easily redownloaded.

5 minutes ago, whitetiger said:

Oh I see, sorry. Only 1 for LanCache. But those files are not that important they can be easily redownloaded.

Only 1 what? I don't understand how that response is related to anything I have said.

13 minutes ago, trurl said:

Post docker run for one of your containers that works with your Movies or media files.

 

9 hours ago, trurl said:

Only 1 what? I don't understand how that response is related to anything I have said.

 

Apologize for late response. To be fair nothing works right now but here is my plex docker run that used to work:

 

docker run
  -d
  --name='binhex-plexpasss'
  --net='host'
  --pids-limit 2048
  --privileged=true
  -e TZ="America/Chicago"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Tower"
  -e HOST_CONTAINERNAME="binhex-plexpasss"
  -e 'TRANS_DIR'='/media/PlexTransCode/'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:32400]/web/index.html'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/plex-icon.png'
  -v '/mnt/user/media/AllMedia/':'/media':'rw'
  -v '/mnt/user/appdata/binhex-plexpass':'/config':'rw' 'binhex/arch-plexpass'

Edit:

Looks like a lot of files were somehow removed from the appdata folder while doing rsync that's why nothing is working. Looks like I need to start from scratch

Edited March 31, 20251 yr by whitetiger

That docker run for binhex-plexpass shows that you do have /media mapped to /mnt/user/media/AllMedia.

 

Why did you say this?

20 hours ago, whitetiger said:

Never touched anything with docker settings other than the appdata path.

How did that mapping get there then? binhex-plexpass template has /media mapped to /mnt/user, which gives it access to all user shares, but you have it limited to only the AllMedia subfolder of your media user share.

 

Do you understand docker volume mapping?

3 hours ago, trurl said:

That docker run for binhex-plexpass shows that you do have /media mapped to /mnt/user/media/AllMedia.

 

Why did you say this?

How did that mapping get there then? binhex-plexpass template has /media mapped to /mnt/user, which gives it access to all user shares, but you have it limited to only the AllMedia subfolder of your media user share.

 

Do you understand docker volume mapping?

 

Because I edited the docker container settings. I was referring to the actual settings page on /settings/docker. 

Regardless, the mapping is not what was causing the issue. I managed to fix most of the issues by recovering some of the data.

 

I'll make an independent share for the dockers that need it. Thanks for your time and help.