Replies: 53 comments 31 replies
-
Similar setup and the same issue here too. Difference from OP is that I use TrueNAS SCALE as storage backend to my Kubernetes cluster. NFS shares are used for storage in my cluster. This setup worked previously with Permissions on TrueNAS:
From within the Immich deployment:
Note that container is running with the UID and GID of The directory is shared to Immich via NFS. One strange thing is that I am able to write to the NFS share from the Immich deployment. The
In contrast to OP, my deployment is never able to create the Log from the main Immich container:
Edit: Upgrading from |
Beta Was this translation helpful? Give feedback.
-
I have the same problem, but after upgrading from version 1.14, not after a clean install. |
Beta Was this translation helpful? Give feedback.
-
Hey, could you please post your NFS mount point config on the immich host machine? |
Beta Was this translation helpful? Give feedback.
-
Please confirm if you're using a networked filesystem and if so, please post your config parameters for that mount point. |
Beta Was this translation helpful? Give feedback.
-
Yes, like the topic author I use cifs. |
Beta Was this translation helpful? Give feedback.
-
I am running a Kubernetes cluster managed by Flux. Hence, I am not mounting the NFS share on the host machine. The NFS share is mounted inside the Immich pod like this: persistence:
upload:
type: nfs
server: <TrueNAS SCALE IP>
path: /mnt/hdd-data/Immich
globalMounts:
- path: /usr/src/app/upload |
Beta Was this translation helpful? Give feedback.
-
I encounter the same issue after updating to v1.115. In addition to this, I am running immich along with tailscale, and the tailscale server complains that connection to immich server is refused, and immich does not start. So, I am guessing that there is some permission setting messed up in the new release. Reverting back to v1.114 solves the issue. Here is the relevant part of docker compose:
and
My OS is Fedora 40 Server Edition. Edit:
|
Beta Was this translation helpful? Give feedback.
-
I am having the same issues after updating from 1.114.0
.env file:
/mnt/media/library is a NFS share My docker-compose.yml
Version 1.114.0 works without issues I can create any file inside the |
Beta Was this translation helpful? Give feedback.
-
I'm also seeing this problem, using a CIFS share, with credentials stored in file (more secure) and accessing a folder on TrueNAS core (but not a specific dataset. I've reset all the permissions on TrueNAS core to be the UID/PID and it was working in 1.14 for me just fine. Can also confirm the file is written just fine on the start of the the docker-compose but fails the check to find the file in [Nest] 17 - 09/14/2024, 8:00:02 AM LOG [Api:StorageService] Verifying system mount folder checks Seems to be in the path for the check has an extra upload/ folder appended maybe? |
Beta Was this translation helpful? Give feedback.
-
Can you all check whether your network mounts are mounted with sync or async writes? |
Beta Was this translation helpful? Give feedback.
-
@bo0tzz I'm not sure how to check this. With |
Beta Was this translation helpful? Give feedback.
-
I'm using the defaults on Debian 12.5 to TrueNAS Core 13.6U2 #https://www.truenas.com/community/threads/why-is-smb-async-and-nfs-sync.107227/ I don't see anything in the underlying config files or TrueNAS config files |
Beta Was this translation helpful? Give feedback.
-
@bo0tzz I edited my comment above, but I am not using network mount. I mount an external HDD in the xfs file system, and I understand that it is mounted with the default |
Beta Was this translation helpful? Give feedback.
-
Can you try mounting explicitly with |
Beta Was this translation helpful? Give feedback.
-
In my case mounting the external hdd (xfs) with |
Beta Was this translation helpful? Give feedback.
-
Turns out the latest code is incompatible, not with writing, but with overwriting hidden files in Windows. This will be fixed in the next release. |
Beta Was this translation helpful? Give feedback.
-
The same problem with a clean installation of v1.115.0 When should I expect the update? |
Beta Was this translation helpful? Give feedback.
-
Experienced the same issue when using CIFS volumes (essentially doing indexing+transcoding on a PC while storing the files on a NAS). Downgraded to 1.114 and it solved it for me. Must be either some breaking change in 1.115 or some bug in it. |
Beta Was this translation helpful? Give feedback.
-
I was able to get v1.115.0 to start by recreating the rm .immich && touch .immich && chmod 666 .immich |
Beta Was this translation helpful? Give feedback.
-
For everyone here, a new release should be coming today (1.116.0) which will resolve the issues with CIFS and windows shares. If you're still experiencing issues after that, it'll either be because of trying and failing to upgrade to 1.115.0, or actual permission problems. There will be some instructions in the release notes if you still experience issues, and if not you can continue posting here or on discord for support 😄 |
Beta Was this translation helpful? Give feedback.
-
Mine is finally working. I had to change my auto mount in /etc/fstab to use a different user. |
Beta Was this translation helpful? Give feedback.
-
I just encountered this error too. and solved it by deleting all the .immich files in the folders. then restarting docker immich is ok. |
Beta Was this translation helpful? Give feedback.
-
I got this error on upload folder. I do not use NFS or network mounted folders. The folder was mounted and working normally on 1.115. This started happening after upgrade from 1.115 to 1.116. Honestly, this could have been my fault - I was cleaning upload folder from orphans, and I potentially might have removed the .immich file. Posting the "repair" steps here for others.
(it's interesting to see
The solution was to
|
Beta Was this translation helpful? Give feedback.
-
I am using v116.2 from HomeAssistant addon build (alexbelgium). It occurred in v115, so I uninstalled, removed directories, and performed a new version install where the problem continues. I created the .immich manually after the error appeared and the output shows in screenshot Other files and folders around the system are all with root and do not have any other user I know of. I am using CIFS; and window share, and it's running on VMware Workstation. |
Beta Was this translation helpful? Give feedback.
-
Same problem with K3S + Longhorn setup. Fresh
|
Beta Was this translation helpful? Give feedback.
-
After removing .immich files from library folders my setup worked again. |
Beta Was this translation helpful? Give feedback.
-
Finally got this to work with v.1.117.0 by logging into the server and creating the .immich files in the 4 folders under the path you have set for UPLOAD_LOCATION in .env. Note I had to create the profile folder too. All done as the same user that the docker runs as (so that permissions align). Now able to start up. The error message is misleading as it says upload/encoded-video which I read as encoded-video should be under the upload folder, but they are separate folders at the root level of the UPLOAD_LOCATION. |
Beta Was this translation helpful? Give feedback.
-
I've been holding off upgrading from 1.114, because of this error, but now we're at 1.120. Has anyone successfully upgraded without manual intervention afterwards? |
Beta Was this translation helpful? Give feedback.
-
I had the same issue, I just edited one path (Backup) in my TrueNAS 24.10 to another location, I even moved the backup files to the new path, but I was not aware of that .immich file, I just moved it to the new location and that was all that I needed. Service started with no issues. |
Beta Was this translation helpful? Give feedback.
-
Running into the same issue on Docker Desktop for Windows. It works if I use v1.114.0 |
Beta Was this translation helpful? Give feedback.
-
The bug
When updating immich server to version v1.115.0, the container does not start. The issue is related to the newly introduced check on mounted volumes.
In my case, the upload folder is a mounted volume from a NAS connected to the LAN. The folder is mounted with what I believe are the right permissions; as a confirmation to this, the .immich file in the "encoded-video" folder gets actually written with a timestamp in it, but soon after that the docker logs show an error opening this file just created and the server refuses to start.
The OS that Immich Server is running on
Ubuntu 22.04
Version of Immich Server
v1.115.0
Version of Immich Mobile App
v1.115.0
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
sudo docker compose pull
sudo docker-compose up -d
Relevant log output
Additional information
The .immich file actually does get written inside the encoded-video folder.
this is the entry in fstab to mount the drive:
//[redacted local ip/Photos /media/photos cifs credentials=/home/[redacted]/.smbcredentials,uid=1000,gid=1000,x-systemd.automount,x-systemd.requires=network-online.target 0 0
these are the permissions of /media/photos
drwxr-xr-x 2 [redacted user - uid 1000] [redacted group - gid 1000] 0 Sep 12 22:00 encoded-video
Beta Was this translation helpful? Give feedback.
All reactions