File storage not connected to NAS
I'm trying to set up immich so that the docker container is running on one device (proxmox ubuntu server docker environment) with the uploaded user files stored on my NAS (truenas SMB share). Despite my best efforts, immich's storage space readout is behaving as if the upload files are going to the limited storage space of the docker environment, not the NAS.
From a search of common issues, this sounds like it's a simple misconfiguration of the network share, however I'm confused by this because I can't find what's wrong with it. I even have other docker containers like jellyfin utilizing the network share without any issue.
I have the SMB share mounted with /etc/fstab like this:
and I have set the immich .env file like so, ensuring that I'm only changing the upload location not database location as recommended:
results of running df -h appears to confirm that /media/TRUENAS/Docker-Files is correctly mounted:


56 Replies
:wave: Hey @Phasedragon,
Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:.
References
- Container Logs:
docker compose logs
docs
- Container Status: docker ps -a
docs
- Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
- Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA
Checklist
I have...
1. :ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time).
2. :ballot_box_with_check: read applicable release notes.
3. :ballot_box_with_check: reviewed the FAQs for known issues.
4. :ballot_box_with_check: reviewed Github for known issues.
5. :ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy).
6. :ballot_box_with_check: uploaded the relevant information (see below).
7. :ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable
(an item can be marked as "complete" by reacting with the appropriate number)
Information
In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider:
- Your docker-compose.yml and .env files.
- Logs from all the containers and their status (see above).
- All the troubleshooting steps you've tried so far.
- Any recent changes you've made to Immich or your system.
- Details about your system (both software/OS and hardware).
- Details about your storage (filesystems, type of disks, output of commands like fdisk -l
and df -h
).
- The version of the Immich server, mobile app, and other relevant pieces.
- Any other information that you think might be relevant.
Please paste files and logs with proper code formatting, and especially avoid blurry screenshots.
Without the right information we can't work out what the problem is. Help us help you ;)
If this ticket can be closed you can use the /close
command, and re-open it later if needed.compose (unmodified from latest release)
.env (only changed UPLOAD_LOCATION and DB_PASSWORD)
The mount needs to be active before immich starts up. That probably isnβt happening
I can cd into the share and see that the files I expect to see are there, unless you mean something else by 'active'?
That needs to be the case before immich is started though
Not just right now
I've tried recreating the immich container multiple times from scratch since then (plus deleting the Docker-Files/immich/library folder)
Successfully submitted, a tag has been added to inform contributors. :white_check_mark:
How did you do this
I'm deploying docker containers from dockge, so deleting the dockge entry which contains the compose and env. Then using ssh to delete the associated folders
You need to prune the images as well if the mount was broken before
huh, why would the image hold onto anything relevant?
Because you were writing inside the image
trying anyway, just curious
:confused2:
That's not how I thought docker worked, huh
It's not how you're supposed to use it, no
any update will wipe the changes of course
is there something I did wrong to make it write inside the image?
wrong would be like Zeus said, the mount was not ready before docker started
We can check this with just an image prune and restart π
no change
could you post the output of
docker inspect immich_server
?
feel free to anonymize the passwordAlright and if you
ls -la /media/TRUENAS/Docker-Files/immich/library
is that empty or what does it show?total 0
drwxr-xr-x 2 root root 0 Aug 25 07:30 .
drwxr-xr-x 2 root root 0 Aug 25 07:30 ..
So docker thinks it's mounted but it's not
Which would point at a permissions issue
ok, I'm pretty sure this user has all the permissions on the network share, so it would be a local permission issue?

I really can't say, network mounts and docker are always funky π
would you have a better suggestion for doing the compute on one device and storage on the other? Or would you find a different arrangement?
One thing you could try is mounting the share directly through the compose in CIFS
oh, I'm not familiar with that
sounds nice though
You would add a volume at the bottom:
And for the immich_server container instead of
You'd do
the
o
section of the volume might need tweaking, I'm not 100% sure on thatyeah, something about it that it doesn't like. Having trouble finding any documentation or example of this though
it's probably the 0 0 π
remove those
ah that's exactly what I was just trying but I'm having trouble getting it to listen to the change
after changing this compose, what should I do besides docker down and docker compose up? Something about this is more stubborn to hold onto the old compose than usual
you should only need to do compose up, is it still complaining about invalid argument?
it's still trying to use the old compose, so same error with same 0 0 despite the new compose not having that
Are you sure you saved the file? π
and are you doing docker down or docker compose down
yes certain, confirmed across different editors
docker down at first, also tried docker compose down now
and dockge is stuck like this, without the ability to confirm because it's a read-only terminal :noooo:

ah... :p
you could try deleting the volume?
trying
is it not docker rm?
removing the stack folder and docker rm doesn't seem to clean it up all the way, something is left over
it's a persistent volume
you need to explicitely delete it from the volumes
I don't know how that works in dockge
dockge is just a light gui on top of compose, doesn't get in the way of doing terminal work. How would you do it by terminal?
docker volume rm
ahh that's what I was missing
- stopped all immich containers
- removed all immich containers
- removed all immich volumes
- pruned images
- removed folder with compose and env
I think that's a clean slate now?
as clean as can be
howw

ok, trying this without dockge
ok different error, that's progress

ohh I don't think the user running docker has access to /home/.smb
I'll copy the .smb over into /opt
hm that wasn't it

I guess it kind of was but this would be a new permissions error? π
Try adding
file_mode=0777,dir_mode=0777
to the o
list @Phasedragonsame response

so hard to tell where the permission denied is coming from
not sure you can mix noprem and dir/file mode π
I suppose that would make sense
:Shrug:

Well I'm somewhat out of ideas here
thanks for trying! At least I learned a few new things