Immich iOS keeps logging out after a day or so

[deep0d0]

The bug

I recently switched from exposing a port on my network to using Cloudflare tunnels to access Immich over the web. Works great, however I’ve noticed that I keep getting logged out after some time.

Sometimes it’s a day, other times a couple. Seems to be when I’m off local internet for some time. I read that some network resiliency was added a while back but not sure if it’s entirely functional. Cloudflare tunnel doesn’t report to be unreachable at any given time.

The OS that Immich Server is running on

unRAID 6.12 - Docker

Version of Immich Server

1.98.1

Version of Immich Mobile App

1.99.0 b 145

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

version: "3.8"

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "immich" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
    ports:
      - 2283:3001
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.yml
    #   service: hwaccel
    command: [ "start.sh", "microservices" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always

  redis:
    container_name: immich_redis
    image: redis:6.2-alpine@sha256:70a7a5b641117670beae0d80658430853896b5ef269ccf00d1827427e3263fa3
    restart: always

  database:
    container_name: immich_postgres
    image: registry.hub.docker.com/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: always

volumes:
  pgdata:
  model-cache:
  tsdata:

Your .env content

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION=./immich-data

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

# Connection secrets for postgres and typesense. You should change these to random passwords
TYPESENSE_API_KEY=key
DB_PASSWORD=passwordb

# The values below this line do not need to be changed
###################################################################################
DB_HOSTNAME=immich_postgres
DB_USERNAME=username
DB_DATABASE_NAME=dbname

REDIS_HOSTNAME=immich_redis

Reproduction steps

1. Login at home
2. Works fine for some time
3. Come back randomly a few days later and I’m logged out. Rest of family also is
...

Additional information

No response

[alextran1502]

Do you think CF was playing a part in this? In my prod setup, I use VPN and never get logged out

[deep0d0]

I don't think so. Cloudflare doesn't report any downtime in the dashboard, and all my other services seem to work fine with no downtime reported. I've installed Uptime Kuma just in case.

But I think this has to do with connectivity between mobile devices and server for some time, maybe in a no service area etc and it gives up on reconnecting

[deep0d0]

FWIW i've updated to 1.99.0 now. In case the app difference was causing an issue.

[alextran1502]

Do you have background backup enabled? Maybe we haven't handled that case gracefully

[deep0d0]

I do indeed have background backup enabled. Can’t trust myself to do timely backups 😂

[alextran1502]

Thank you, I think it might be the cause. Let me see if I can handle the case it cannot connect to the server gracefully

[deep0d0]

Sounds good. Let me know if I can provide any additional information or logs

[mmomjian]

I'm still having this issue with 1.99.0. I am running Immich behind Nginx (publically accessible). No VPN or CF tunnels. Happy to provide logs if helpful.

[alextran1502]

@mmomjian Do you also use background backup as well?

[mmomjian]

Yes, I do @alextran1502

[mmomjian]

Sorry for the bump but do we have any update on this? It is really hurting the wife-approval factor :/ Happy to provide any logs. It happens about 3-4 times / week, when it happens I get a cannot set success login info followed by logout failed for <username> in the app logs.

I am not using tailscale or anything like that. so I don't anticipate that the server is actually unreachable for any reason. The first error seen reads as below:

Cannot set success login info

FormatException: Unexpected character (at character 1)
<!doctype html>
^

From: SplashScreenPage

#0      _ChunkedJsonParser.fail (dart:convert-patch/convert_patch.dart:1376)
#1      _ChunkedJsonParser.parseNumber (dart:convert-patch/convert_patch.dart:1243)
#2      _ChunkedJsonParser.parse (dart:convert-patch/convert_patch.dart:908)
#3      _parseJson (dart:convert-patch/convert_patch.dart:35)
#4      JsonDecoder.convert (dart:convert/json.dart:610)
#5      JsonCodec.decode (dart:convert/json.dart:216)
#6      ApiClient.deserialize.<anonymous closure> (package:openapi/api_client.dart:158)
#7      compute.<anonymous closure> (package:flutter/src/foundation/_isolates_io.dart:19)
#8      _RemoteRunner._run (dart:isolate:1090)
#9      _RemoteRunner._remoteExecute (dart:isolate:1084)
#10     _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:300)
#11     _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:184)

[deep0d0]

You know what, I kinda forgot about this because it hasn’t happened in a while.

actually I moved to a new server, same setup on Unraid and running behind CF Tunnel still but I guess I am not overloading the server so it’s fine?

[mmomjian]

Glad to hear it hasn't been happening! I don't suspect an overload being the issue here, I don't have any big imports or anything going on and the server is pretty beefy.

[mmomjian]

I think the issue is somewhere in mobile/lib/shared/views/splash_screen.dart:44-62. I'm not sure why the catch is being triggered to begin with, but once it is, it seems to call the .logout() method which explains the second logout failed error and why the app logs itself out.

I don't see anything in the nginx logs indicating any failed backend requests around this time, so I'm pretty stumped. I enabled finest and debug logging, maybe that will help next time. I don't use any Authentik/Authelia/etc, just plain Immich login.

[alextran1502]

@mmomjian What do you use for your wife to access the instance while not on the local WIFI network?

[mmomjian]

@alextran1502 sort of a complex deployment, but I run nginx on an Oracle VPS which proxies traffic to my home server over an internal tailscale network. From the perspective of the end user/app, Immich is never "local" - we connect to a public domain name with a real (LetsEncrypt) SSL cert. I run Uptime Kuma to monitor my services, it checks Immich every 10 minutes - I just dropped that to q1min in case there's some kind of weird nginx failure taking place, but all the other services I run have been rock solid.

[alextran1502]

Thank you for the input, let me try remove that logout condition on the splash_screen to see if it helps

[jrasm91]

It looks like it is checking at the root instead of at /api. The prior returns html for the website.

[alextran1502]

@jrasm91 where are you seeing this?

[mmomjian]

It looks like it is checking at the root instead of at /api. The prior returns html for the website.

That sort of makes sense, because for my login url in the app I use https://subdomain.domain.com, with no /api suffix. However it seems to work fine - except for in this example? I'm not sure how the app checks for the root vs the /api subdomain and if maybe that check is not being done in this case?

[jrasm91]

[Kwinnieprince]

It looks like it is checking at the root instead of at /api. The prior returns html for the website.

That sort of makes sense, because for my login url in the app I use https://subdomain.domain.com, with no /api suffix. However it seems to work fine - except for in this example? I'm not sure how the app checks for the root vs the /api subdomain and if maybe that check is not being done in this case?

I have the same issue, for me it logs out about every day or so. i am hosting it behind an proxy but randomly it logs out.

If you woud want logs, i can check for those :)

[aka-swork]

+1

For me, it happens too. And it’s really annoying. Even my grandma complains that she can’t open photos without entering credentials. 😅

[mmomjian]

Just had it happen again today. Here's a summary of the logs.

The time of 09:41 is the time at which I opened the app and it was logged out.

09:41: Unable to get user information from the server. From: AuthenticatioNotifier
09:41: Unable to get user information from the server. From: AuthenticatioNotifier
09:42: Ignoring socket cache for http://immichurl
09:42: readyState closed

I switched my login URL to add the /api suffix and will see if that helps.

[mmomjian]

Not intending to reopen this, but it happened to me today again while using the /api endpoint. Strangely, no logs at all were generated - I had to force close the app and when I reopened, the logs had a 12-ish hour empty spot from yesterday evening to the time I opened it. I know there was another PR merged recently that was related to failing logging so that might fix that as well. I saw a PR was merged to hopefully fix this logout as well.

[mmomjian]

@alextran1502 unfortunately the same thing happened again this morning.

If you prefer this as a new issue let me know.

Access: public-facing domain name

Server version: 1.102.3
App version: 1.102.0

[bo0tzz]

afaict the fix for this got reverted in #8954 while chasing another logout issue (#8974)

[alextran1502]

@mmomjian Do you still have the log above that you can share? I would like to see the stack trace of "Unable to get user information from the server"

[mmomjian]

@alextran1502 cant post a screenshot RN but no stack. Just that message and “from: AuthenticationNotifier”

The only one of those 3 red messages that had a stack is the one I posted.

[mmomjian]

Screenshots from crash + logout.

[bo0tzz]

This thread has been going for a while, but I think it's a duplicate of #2980?

[mmomjian]

This thread has been going for a while, but I think it's a duplicate of #2980?

At first glance I don’t think so - #2980 reports relating to Tailscale use. This issue is pretty much exclusively people using a real public domain name. Additionally, there is a wealth of logs and affected users subscribed to this issue, so I believe it should stay open.

[bo0tzz]

The circumstances are different, but the effect - Immich logging out because it failed to connect to the server - is the same.

[thunderclap82]

This is happening to me as well. I'm on 1.104.

[deep0d0]

I might add that the logging out stopped for some time and then has started to happen again. Perhaps one of the fixes has adverse effects?

[truncsphere]

This is happening to one of our iPhones on a regular basis as well which is annoying said user to the point they almost won't use the app anymore. As I'm trying to dump the other "not named" app I would love to see the app not force logout.
Also this is not happening on Android.

[alextran1502]

@truncsphere The current workout for this iOS issue is disabling background backup. I will have to rework the entire authentication flow to fix this issue since none of the remediation works

[traktuner]

@truncsphere The current workout for this iOS issue is disabling background backup. I will have to rework the entire authentication flow to fix this issue since none of the remediation works

Thanks, @alextran1502
No Cloudflare here. Immich directly exposed. iOS users on different devices have this issue on a regular basis on the local network and remote.
The logout issue happens on the devices even if the Immich instance is OK and online and the user-devices have a working internet connection.
I hope the auth-rework fixes this issue once and for all since background uploads are a key feature which we won't turn off.

[klejejs]

Hi! I also have a direct connection to my server and the instance is online 24/7. Didn't have log-out issues until I updated to 1.107, now I have had a few log-outs during the past few days. The logs show the following:

The first error (from the bottom) has this message (others did not have anything valuable):

ApiException 400: HTTP connection failed: GET /users/me (Inner exception: Bad file descriptor)

#0      IOClient.send (package:http/src/io_client.dart:96)
<asynchronous suspension>
#1      BaseClient._sendUnstreamed (package:http/src/base_client.dart:93)
<asynchronous suspension>
#2      ApiClient.invokeAPI (package:openapi/api_client.dart:101)
<asynchronous suspension>
#3      UsersApi.getMyUser (package:openapi/api/users_api.dart:210)
<asynchronous suspension>
#4      AuthenticationNotifier.setSuccessLoginInfo (package:immich_mobile/providers/authentication.provider.dart:182)
<asynchronous suspension>
#5      SplashScreenPage.build.performLoggingIn (package:immich_mobile/pages/common/splash_screen.page.dart:55)
<asynchronous suspension>

[juliienp]

Hi! I also have a direct connection to my server and the instance is online 24/7. Didn't have log-out issues until I updated to 1.107, now I have had a few log-outs during the past few days. The logs show the following: The first error (from the bottom) has this message (others did not have anything valuable):

ApiException 400: HTTP connection failed: GET /users/me (Inner exception: Bad file descriptor)

#0      IOClient.send (package:http/src/io_client.dart:96)
<asynchronous suspension>
#1      BaseClient._sendUnstreamed (package:http/src/base_client.dart:93)
<asynchronous suspension>
#2      ApiClient.invokeAPI (package:openapi/api_client.dart:101)
<asynchronous suspension>
#3      UsersApi.getMyUser (package:openapi/api/users_api.dart:210)
<asynchronous suspension>
#4      AuthenticationNotifier.setSuccessLoginInfo (package:immich_mobile/providers/authentication.provider.dart:182)
<asynchronous suspension>
#5      SplashScreenPage.build.performLoggingIn (package:immich_mobile/pages/common/splash_screen.page.dart:55)
<asynchronous suspension>

Hey, I have the same problem, yesterday with v1.107.2 on my ios device and server :

When the request /users/me failed, the app force to logout.
But in my situation it was a connectivity failure, I don't think the application should disconnect when a first attempt failed to reach the server.

[glaeqen]

@truncsphere The current workout for this iOS issue is disabling background backup. I will have to rework the entire authentication flow to fix this issue since none of the remediation works

Ok, great to know that backing up manually is a viable workaround. I'm having exact same issue with a very vanilla setup, server is behind a public IP with Google OAuth auth only. Looking forward to the fix ❤️

[genebean]

Same issue on app 1.108.0 build.163 and server 1.108.0

[freexd0m0329]

Same issue on iOS App 1.108.0 build.163.
Happened about every 3-4 days, I use PPPoE to dial up and DDNS to make sure my IP and domain is matching. Maybe there is about 5 mins delay when updating IP address. Then immich App try to connect to my server using domain which resolved to old IP address causes the problem.

[Tronix117]

Same here for what it's worth.
Using cloudflare + google auth, background save enabled.