Storage management in Immich?

[andreasdueren]

@jdaviescoates I'm not seeing how I can tell Immich to store the files on the external drive. For that I'd need modify the .env file.

[nebulon]

Maybe the external library feature would work with Immich as mentioned in https://forum.cloudron.io/topic/13587/mount-nextcloud-data-as-immich-external-library

[andreasdueren]

@nebulon I've looked into it but from what I understand these are read only from the APP. I'd like to use the app for uploading, not just viewing.

[perelin]

Same use case here: would like to manage my photos with Immich, but want/need to store them on a Hetzner Storage Box (or any other external storage). My library is just to big to put it on the actual Cloudron Server. How can this be achieved? Did not find any clear path to this. Storage Templates maybe?

[jdaviescoates]

Could we not just use the config settings shown here to point at mounted Cloudron Volume? https://immich.app/docs/guides/custom-locations/

[andreasdueren]

@jdaviescoates nope, since we don't have access to the dotenv file

[jdaviescoates]

@andreasdueren said in Storage management in Immich?:

@jdaviescoates nope, since we don't have access to the dotenv file

Sounds to my like @staff just need to add a symlinked .env file to the package that we can add config options too using the File Manager, just like many other packages already have?

[joseph]

I think the immich approach is to set thing in /app/data/immich.json

[perelin]

@joseph the immich.json does not expose a config setting for the file upload/storage path [1]. Looks like the way to go is the env var UPLOAD_LOCATION [2]

[1] https://immich.app/docs/install/config-file/
[2] https://immich.app/docs/install/environment-variables/#docker-compose

[nebulon]

So those env variables are for the immich docker compose environment, which Cloudron does not use. So they won't help us here. The config file does not have this, since it is not something which should be configured.

Instead like the docker compose setup, our package needs to be able to deal with paths accordingly, so we would have to essentially introduce our own "env" vars to define paths to be able to use Cloudron volume mounts. However given that those are not backed up in the same way main app storage is, a restore will inevitably cause issues with the files in storage getting out of sync with the app's database.

All in all I am really not sure if we should even lead users down that path with the risk involved for the benefit of cheaper storage

[perelin]

To understand the issue: when I restore a backup there might possibly be

a) new photos in the external store that are not in the restored db because they were added to Immich in inbetween backup and restore time

and/or

b) photos missing in the external store that are still in the restored db because they have been deleted from Immich inbetween backup and restore time

Both sound like states that Immich should address at some point in their ongoing development. Either re-index the storage path or clean db of file entries no longer available. But I have not checked if they have discussions ongoing about such features.

I generally would opt for letting users shoot themselves in the foot, given enough red, bold disclaimers

[jdaviescoates]

Yeah, I mean, I don't see how Immich is really any different to Calibre Web, Navidrome, Jellyfin etc etc that all allow for custom paths for the location of their libraries and just routinely reindex that location occasionally

[perelin]

@nebulon are you open to explore this further at some point in the future? Immich seems pretty pointless (to me) without the option to plug-in your own storage.

[jdaviescoates]

@perelin I think best bet is to relay that upstream directly to Immich

[perelin]

@jdaviescoates Hard to make a case there when all of their installation methods are somewhat around Docker Compose or similar systems.

From their Docker Compose file I can see that they just mount an external folder to their internal, hardwired upload location -> https://github.com/immich-app/immich/releases/download/v1.132.3/docker-compose.yml

I dont know where I can lookup the Cloudron/Immich integration, but I guess the mounting could happen when the Dockerfile gets run. But of course at first there is no mounted file system available

[perelin]

So, after some exchanges in the Immich Discord I managed to switch my existing Immich Photo Library to an external volume on a Hetzner Storage Box by copying the files (./upload/*) and setting the IMMICH_MEDIA_LOCATION to a mounted storage volume in /media/
Immich started up again and displayed all my photos.
BUT: it seems I cant upload new photos Not sure why, the /media/ mounted volume (Hetzner Storage Box) seems to have full permissions. Here is the Immich log when trying to upload a file:

May 20 09:21:41 [Nest] 61 - 05/20/2025, 7:21:41 AM ERROR [Api:ErrorInterceptor~7wmg4ktf] Unknown error: Error: EPERM: operation not permitted, utime '/media/FSN1-BX1401/photos/immich/upload/bf2f33b8-b8b4-4f5d-9619-62e462afa3fd/a7/d2/a7d2dc05-0b07-4aca-977f-193026f26430.HEIC'
May 20 09:21:41 Error: EPERM: operation not permitted, utime '/media/FSN1-BX1401/photos/immich/upload/bf2f33b8-b8b4-4f5d-9619-62e462afa3fd/a7/d2/a7d2dc05-0b07-4aca-977f-193026f26430.HEIC'
May 20 09:21:41 at async Object.utimes (node:internal/fs/promises:1127:10)
May 20 09:21:41 at async AssetMediaService.create (/usr/src/app/dist/services/asset-media.service.js:293:9)
May 20 09:21:41 at async AssetMediaService.uploadAsset (/usr/src/app/dist/services/asset-media.service.js27)
May 20 09:21:41 at async AssetMediaController.uploadAsset (/usr/src/app/dist/controllers/asset-media.controller.js:40:29)

Any ideas how to debug this?

[nebulon]

Immich runs as the cloudron user within the container. If you open a webterminal into the app, can you check if that user has write permissions to the /media/... volume?

[perelin]

Yes, tried that - basic permissions look good. It seem to be an issue with Immich trying to use utime to change timestamps on the mounted share which seem to be an issue somehow for the cloudron user. Some testing on my box shows:

Creating a testfile (touch .test) on the mounted share and then trying to change the timestamp

• works for root (-> touch -t 202501010000 .test)
• does not work for cloudron (-> sudo -u cloudron touch -t 202501010000 .test)

Not sure how to continue.

[nebulon]

For a start, how did you mount the storage box? both SSHFS and CIFS are quite particular about users and permissions. One reason why we don't support moving the main app directory onto such mount points...

[perelin]

I mounted it with the Cloudron build in mount option in the UI. Are there other options? I guess editing fstab by hand will be overwritten at some point

Here is the output of the mountcommand from the console.

root@81deeb68-0628-45ff-bf4c-0e9e294e7935:/media/FSN1-BX1401# mount | grep FSN1-BX1401
//u452885.your-storagebox.de/backup on /media/FSN1-BX1401 type cifs (rw,relatime,vers=3.1.1,cache=strict,username=u452885,uid=808,forceuid,gid=808,forcegid,addr=2a01:04f8:2b03:0981:0000:0000:0000:0002,file_mode=0666,dir_mode=0777,iocharset=utf8,seal,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)