Move images from internal storage to external library

[hupfdule]

I am using Immich already with curated external libraries.

What I would really like to do is to use it for the bulk of images in my (and my spouses) phone, too.
My idea is to let Immich upload the images from the phone into its internal storage so they end up in the timeline (that should work without a problem).

I would like to be able to organize the photos of special interest (e.g. of specific events) into different folders. That should be possible by utilizing Storage Templates and using the album name as a subfolder in the Storage Template.

I would then want to move these folders with that images to an external library.
The one thing I am afraid of is the following note in https://immich.app/docs/administration/backup-and-restore#asset-types-and-storage-locations:

danger Do not touch the files inside these folders under any circumstances except taking a backup. Changing or removing an asset can cause untracked and missing files. You can think of it as App-Which-Must-Not-Be-Named, the only access to viewing, changing and deleting assets is only through the mobile or browser interface.

This sounds like moving images from Immichs internal storage to an external library on filesystem level is a bad idea.

But what does actually happen in such a case? What is this warning referring to?

And what is the recommended approach for doing this? How can I move images from the internal storage (that are already visible in the timeline) to a external library?

[bo0tzz]

This sounds like moving images from Immichs internal storage to an external library on filesystem level is a bad idea.

Correct

But what does actually happen in such a case?

Immich will not realise the files were moved, and all kinds of stuff will break when it fails to find them where it expects.

There is no recommended approach for this. You'll probably need to copy the files and then manually delete the internal library ones via the Immich GUI.

[andreiled]

You'll probably need to copy the files and then manually delete the internal library ones via the Immich GUI.

I tried something similar and it didn't work:

1. This is probably irrelevant, but I copied the files to my external library via another cloud rather than from the Immich's own library directory
2. It seemed to work at first (i.e. Immich recognized the duplicates, after which I trashed the file copies uploaded by the app) but the Android app promptly re-uploaded the images after I emptied the trash.

I assume that enabling the experimental feature to sync deletions to Android app may have prevented the app from re-uploading the images but I do not want to have to remove all photos from my phone just to prevent the app from re-uploading them.

[chrislxn]

There's an idea, not verified but may work:
move the files and keep the data structures to a new location, Use a Symbolic link to refer your old folder to the new location

[hupfdule]

I also didn’t try it, but don’t expect this to work. As the internal ind the external library are totally separated in Immich the symbolic link would probably only lead to duplictes of all these files.

I think I will try @bo0tzz idea first an copy the relevant files and delete them afterwards from within Immich. Only an ugly workaround, but a least sounds as it would work until Immichs support of external libraries gets improved (if this will happen).

[Nordlicht-13]

I have the same workflow.
I changed to this:
Immich is not uploading the images anymore.
Set up syncthing to load immages to my TrueNAS
Storting images into the external library.

It would be nice to have a extended delete-function to delete a image from the library and force deleting the file as well.

[bdovaz]

I have a very similar use case, I would like to keep my folders as I have them organized on disk so I would like new uploads from internal storage to be able to move them to external storage and select N files and move them to a particular folder on external storage in bulk.

@bo0tzz is this use case intended to be developed at some point?

[bo0tzz]

Please don't ping to ask for updates; if there are any, they'll be in a comment here.

[ruocchio]

I have the same workflow where I treat auto uploads as temporary storage and then move the images to a permanent decade/year/event permanent storage location that is independent from the photo mgmt application. A simple Move or Cut/Paste operation within Immich folders would be ideal. I hate to say it, but much like Synology Photos (which I'm trying to get away from) does.

[DanielK990]

I haven't tried it yet, but would this not possible using the API in a script? First, export images on a per album basis to the storage location of the external library and afterwards deleting the images from the internal library via API?

[andreiled]

Based on my experience, I believe doing this will result in the phone app re-uploading the images.

---

Granted, what I did is slightly different from the suggested sequence of steps above, I believe the net effect will be the same:

1. Having recently enabled backup in the Android app, I took a few photos using my phone, after which the app auto-uploaded the photos to Immich.
2. Another file sync app I have uploaded the same images to a cloud.
3. I downloaded the images from that other cloud and manually put them into my external library that I curate myself.
4. After the nightly library scan, duplicates appeared in the timeline: one copy uploaded by the Android app and another copy from the external library.
5. I trashed the copies uploaded by the app in favor of copies that I put manually into the external library and emptied the trash.
6. To my surprise, the Android app re-uploaded the images, i.e. it appears that, instead of remembering that it already uploaded those images, the app tries to make sure that all images available on the phone are also present in the library.

Perhaps, enabling the feature to sync deletions from Immich to the Android app may have prevented the latter but I do want to leave most of my images readily available on the phone (i.e. I do not want to remove all photos from the phone just to prevent the app from creating duplicates).

[andreiled]

I have a very similar workflow with the caveat that a good chunk of my library comes form my camera (which I upload manually).

After some experimentation, here's my hot take: I do not need Immich to have an actual Move button or anything like that since I mount my external library in read-only and do not intend to change that (for one, I see that as an additional security measure to mitigate the risk of my Immich instance getting hacked).

Instead, I believe that the workflow described here can work if Immich supported at least one of the following (preferably both):

1. Automatically trash the asset in the main library when detecting an exact duplicate with an asset in an external library of the same user.

   I observed that, after moving an image file from Immich's library directory to a directory in my own library (mounted as an external library in Immich), Immich will still recognize the two assets ('orphaned' asset in the main library and the new asset in the external library) as duplicates.
   Automating duplicates resolution in this case will be a great quality of life improvement.

2. Extend the hash-based dedupe that presumably happens at the upload time to take into account external libraries. In other words, do not auto-upload to the main library any photo that is an exact duplicate of some existing photo from an external library of the same user.

   I assume this will require some tweaks how checksums are calculated for files in external libraries, e.g. to store a second checksum computed using the same logic as used for files in the main library.

   This is necessary to prevent mobile apps from re-uploading moved photos after emptying the trash (since emptying the Trash seems to cause Immich to lose the information that the files were moved).

What do you all think about this approach?

While I am not one of the devs, I could try to implement above improvements as long as the devs here do not see this as violating some internal design principles.

[andreiled]

Quick update:

1. I filed a feature request for the first part ([Feature] Auto-trash internal library assets duplicating assets in an external library exactly #22654) but there's no appetite for adding this kind of feature directly into Immich even if I go and build it myself (see my last comment there).
2. Based on a quick conversation with maintainers, I created a simple automation script that detects and reconciles the kind of duplicates that appear when copying or moving original files from the internal library to an external library: https://github.com/andreiled/immich-reconcile-assets-with-external-copy

[Dampfwalze]

I came across this, because my parents got a new NAS and I want to setup Immich for them. They used to archive their images similar to the mentioned scheme {date}-{event_name}/{filename}.{ext}. And they won't change that soon (moreover I don't belive they have to). Of course their existing library would be included as an external library. But now, it must be possible to take new photos, synced to Immich, and archive them into the external library.

For that they need a simple, foolproof method. I would prefer if they can just move an album inside Immich to the external library. And also later add more images to that album. File naming would be handled via the album name. The only missing part is the moving of the files.

Without Immich supporting it, it is really difficult to get that to work, because Immich has its own DB that musst be updated as well. Ideally you want to keep all Metadata. This includes the albums it is in, people in the image and so on. You certainly don't want to run all the ML on those images again either. And in many setups, both locations live on the same filesystem. So ideally, files would only be moved, instead of being copied.

The most atomic operation Immich must support is moving individual files to another location. I assume this only includes updating the file pointer in its DB. Special care must be taken that a new location on the same file system is only moved instead of copied, also across container mount point boundaries. Shell commands like mv usually don't play nice with that. So the work must be handed over to the kernel via a system call (the std lib likely already implements the system call). Only it can see that the fs is the same and a copy is not necessary.

So a great start would be to implement an API for exactly that: Moving one file location to somewhere else, including an external library. That would be enough so at least you could build an external tool/skript to handle the initial problem.

[timonrieger]

i see the case. In short it likely comes down to: having an external library but wanting to continuously upload to it, so that photos stay in one location. without any official confirmation, but
a) there is a feature freeze on external libraries
b) workflows are WIP
So this case might already be in consideration and be enabled by any/both of these

[Dampfwalze]

Almost. I still want to upload and sync every day stuff in Immich's main library, but then be able to selectively move images to the external library, with the added step of sorting them into albums. This manual step is a requirement. The external library should be a well controlled location, where everything is intentional.

Would the proposed feature of having an API to move image locations fall under the feature freeze? And if yes, how long will the feature freeze be ongoing? It would be quite a small patch, I am pretty sure. It is just the bare minimum to enable innovation.

[timonrieger]

you can ask those questions in Discord under #contributing 😄 . There you'll get a better answer…

[erikpienk]

Just now I am having this issue. I find my library organization to be close to perfect so I prefer to use it, and as also in the future if immich disappears or I need to change software I need those folders to have a manual organization. I tried the immich upload but it seems to be problematic when I want to move files to the external library. Hopes this gets added as many users would love to have total control of their libraries.