My Immich container is loosing mount points, I feel like an idiot and not sure what might be wrong:

This are my mount points:

They can be confirmed in the portainer(ignore extra ones):

And normally when I inspect the folder I should see something like below:

However, every single day I have immich issue in the log etc. saying that it cannot find "encoded-video" folder, then when I check what is in the folder:

Simple container restart fixes the issue, but why, and how is it possible that it loses the access?

I have 72 containers running, there are no issues with anything else, only with Immich.

My appdata is on zfs and files are not moved to the array, there is nothing else using these files, immich is running under 99 user and all files have proper rights. What is happening with this thing? Please advise.

What I have done now as test I changed mount points to /mnt/cache instead of /mnt/user

Edited June 11, 20251 yr by Joloxx9

you most likely have a primary and secondary storage setup for the appdata share in your unraid share settings. This is breaking your docker bind mounts when in use.
(That or system resources overload and limits need set...)

Moving to disk paths (hardlinks over the unraid fuse system...:
/mnt/cache instead of /mnt/user

This is a good start... (the share settings still affect this...) should help but you need to fix all docker template paths to be at there correct location...

Since you said your using zfs..

/mnt/cache seems incorrect NOT ENOUTH INFO TO ASSIST!

unless you named your zfs pool cache...


Please post a unraid diagnostic and share the settings for your share tab...

Make sure that appdata is a dataset and is correctly setup to write to the zfs dataset...

4 hours ago, bmartino1 said:

you most likely have a primary and secondary storage setup for the appdata share in your unraid share settings. This is breaking your docker bind mounts when in use.
(That or system resources overload and limits need set...)

Moving to disk paths (hardlinks over the unraid fuse system...:
/mnt/cache instead of /mnt/user

This is a good start... (the share settings still affect this...) should help but you need to fix all docker template paths to be at there correct location...

Since you said your using zfs..

/mnt/cache seems incorrect NOT ENOUTH INFO TO ASSIST!

unless you named your zfs pool cache...


Please post a unraid diagnostic and share the settings for your share tab...

Make sure that appdata is a dataset and is correctly setup to write to the zfs dataset...

Thank you for your answer.

Few people answered in quite similar way, on unraid discord, immich discord and docker forums, all of you are pointing on the same thing, folder(s) should be moving and that could break mount.

HOWEVER I can already answer this is not the case.

My appdata share was set in following way main storage - cache, secondary storage array, mover: cache<-array. So technically my files should not move from cache, especially when I have 2TB on the cache and it is never over 50% of utilisation. However anything was possible, hence why gents on discord advised to disable secondary storage, enable exclusive shares etc. And guess what, unfortunately same thing. The 3 folders were gone this morning and immich spammed me with issues.

My cache is using zfs mirror, hence why I said I might use /mnt/cache/appdata/etc... because that is the right direct path to the file, however what I have done this morning, I removed the affected 3 binds(left thumbs as there are no issues with it, and this one MUST be on nvme).

Immich without these mounts automatically use default folder locations, hence why I moved all stuff to these folders and I am testing it. If it is ok for 24 hours, I will move them to another location, as I have a pool of 3 older sata ssd drives in runnign raidz1 so can try if that mount will work.

If that is ok I might leave them there or try to use /mnt/cache mount as a test.

However if this will keep failing I might have to run diagnostic.

What is quite interesting, once I set it up with exclusive shares yesterday, it was good untill midnight, what was scheduled at midnight? External library scan in immich. What is even more interesting, day before had same issues at the same time.

Please see attached log. I have changed cron this morning and run that hour ago, no issues when folders are in their default location.

log short.txt

Edited June 10, 20251 yr by Joloxx9

We solved the issue in discord, basically immich creates subfolders under it's preconfigued "photos" path. Those folders have to exist in their location regardless if you set their location to another share entirely.

For example, these folders cannot be deleted(left photo) otherwise the link is broken even though these folders have been set to a different location (right photo):

The OP seems to have mover deleting the empty folders (left photo) when mover is ran which results in a broken link.

Edited June 10, 20251 yr by MowMdown

Tested, folders moved to disk1, mover doesn't remove them anymore, link bewteen host and docker is no longer broken. Hopefully this might help someone in the future.

Keep in mind, do not keep dummy/empty folders created by immich on cache drive.

Edited June 10, 20251 yr by Joloxx9

the issue is that you have secondary setup at all appdata should not and can't support this

""""""""secondary storage array, mover: cache<-array""""""""""

Remove secondary and make sure all files exist on 1 primary disk for data and location.

as new fiels are written to the primary disk and previous data doesn't exist on cache...

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

https://docs.unraid.net/unraid-os/manual/shares/

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

Your using unraid fuse (/mn/user) and mover wrong in unraid... thus you need to answer the question of who touched what where. And where is that data stored at now?

Edited June 10, 20251 yr by bmartino1
hate new forum...

9 minutes ago, bmartino1 said:

the issue is that you have secondary setup at all appdata should not and can't support this

That wasn't the problem.

7 hours ago, Joloxx9 said:

Tested, folders moved to disk1, mover doesn't remove them anymore, link bewteen host and docker is no longer broken. Hopefully this might help someone in the future.

Keep in mind, do not keep dummy/empty folders created by immich on cache drive.

Keeping them on cache drive is fine, default mover does not delete empty folders after it moves them to the array.

I’m positive this issue is only present when mover turning plugin is used in conjunction with its “delete empty folders” setting enabled.

Edited June 10, 20251 yr by MowMdown

I would rather move them to the disk, just to avoid things like that, in the future mover might remove empty folders and users might go crazy with that. Especially that immich is growing. Hopefully they will change it at some point and these dummy folders wont be needed anymore.