Storage management in Immich?
-
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
-
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
-
@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.
@perelin I think best bet is to relay that upstream directly to Immich
-
@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
-
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 photosNot 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?
-
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 thecloudron
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.
- works for
-
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
mount
command 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)
-
right, so the issue is, CIFS with hetzner only knows one uid which is set there in the mount option. This means there are no real user IDs....does it work if you give all users? Although it is still unclear why you can write but not change
mtime
attribute via touch ascloudron
user, if I understand correctly.I guess that needs more investigation on how to maybe workaround that...
-
right, so the issue is, CIFS with hetzner only knows one uid which is set there in the mount option. This means there are no real user IDs....does it work if you give all users? Although it is still unclear why you can write but not change
mtime
attribute via touch ascloudron
user, if I understand correctly.I guess that needs more investigation on how to maybe workaround that...
@nebulon said in Storage management in Immich?:
does it work if you give all users?
Not sure what you mean here. Mounting the share with other options? I had the impression I can not do that by myself since its managed by Cloudron.
Would love to make this work. If you tell me what to try Im happy put some time in
-
oh right
well you will hit other side-effects then with apps if the filesystem is not actually support those features. This is one of the reasons, we only allow to move the app itself onto very specific filesystems like xfs and ext4. Not sure what can be done if CIFS with hetzner does not allow this. Or maybe you can investigate if you setup the mountpoint manually on the system with other mount options?
-
Footnote: sadly Immich already decided to not support setups where utime is not availble: https://github.com/immich-app/immich/issues/14005