Web Server Session Timeout? #14985

New Issue

GiteaMirror · 2025-11-02T11:27:19-06:00

GiteaMirror commented

2025-11-02 11:27:19 -06:00

Originally created by @petersrinivasan on GitHub (Sep 25, 2025).

Description

Server:
Gitea Version 1.24.6 Official Docker Image
Docker v28.4.0
Debian 13.1 (Trixie) LXC
Proxmox 9.0.9

Reverse Proxy:
Caddy Plugin v2.0.2_2
OPNSense 25.7.1

Client:
Chrome v140.0.7339.186
Windows 11

If I leave my gitea tab on my browser open over night, in the morning, gitea web interface no longer functions; 500 error. In the logs, I get stuff like:

2025/09/25 17:14:18 routers/web/auth/auth.go:150:CheckAutoLogin() [E] autoSignIn: unable to updateSession: regenerate session: open /var/lib/gitea/data/sessions/e/9/e95bdc21b048d4fa: permission denied
2025/09/25 17:14:18 HTTPRequest [I] router: completed GET /user/login for [IP REDACTED], 500 Internal Server Error in 4.3ms @ auth/auth.go:184(auth.SignIn)
2025/09/25 17:20:22 HTTPRequest [I] router: completed GET /[ORGANIZATION REDACTED/[REPO REDACTED].git/info/refs?service=git-receive-pack for 192.168.72.96:0, 401 Unauthorized in 2.7ms @ repo/githttp.go:511(repo.GetInfoRefs)

If I clear the page's application data, it works again. If I restart the container, it works again. Git operations to my remote origin work fine. Appears to be some kind of session timeout.

Gitea Version

1.24.6

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.49.1

Operating System

Debian 13.1

How are you running Gitea?

Docker Compose

  GNU nano 8.4                             docker-compose.yaml                                       services:
  server:
    image: docker.gitea.com/gitea:latest-rootless
    environment:
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=[REDACTED]
    restart: always
    volumes:
      - /mnt/gitea/data:/var/lib/gitea
      - /mnt/gitea/config:/etc/gitea
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:2222"
    depends_on:
      - db

  db:
    image: docker.io/library/postgres:14
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=[REDACTED]
      - POSTGRES_DB=gitea
    volumes:
      - ./postgres:/var/lib/postgresql/data

Database

PostgreSQL

Originally created by @petersrinivasan on GitHub (Sep 25, 2025). ### Description **Server:** Gitea Version 1.24.6 Official Docker Image Docker v28.4.0 Debian 13.1 (Trixie) LXC Proxmox 9.0.9 **Reverse Proxy:** Caddy Plugin v2.0.2_2 OPNSense 25.7.1 **Client:** Chrome v140.0.7339.186 Windows 11 If I leave my gitea tab on my browser open over night, in the morning, gitea web interface no longer functions; 500 error. In the logs, I get stuff like: ``` 2025/09/25 17:14:18 routers/web/auth/auth.go:150:CheckAutoLogin() [E] autoSignIn: unable to updateSession: regenerate session: open /var/lib/gitea/data/sessions/e/9/e95bdc21b048d4fa: permission denied 2025/09/25 17:14:18 HTTPRequest [I] router: completed GET /user/login for [IP REDACTED], 500 Internal Server Error in 4.3ms @ auth/auth.go:184(auth.SignIn) 2025/09/25 17:20:22 HTTPRequest [I] router: completed GET /[ORGANIZATION REDACTED/[REPO REDACTED].git/info/refs?service=git-receive-pack for 192.168.72.96:0, 401 Unauthorized in 2.7ms @ repo/githttp.go:511(repo.GetInfoRefs) ``` If I clear the page's application data, it works again. If I restart the container, it works again. Git operations to my remote origin work fine. Appears to be some kind of session timeout. ### Gitea Version 1.24.6 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.49.1 ### Operating System Debian 13.1 ### How are you running Gitea? Docker Compose ``` GNU nano 8.4 docker-compose.yaml services: server: image: docker.gitea.com/gitea:latest-rootless environment: - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=db:5432 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=[REDACTED] restart: always volumes: - /mnt/gitea/data:/var/lib/gitea - /mnt/gitea/config:/etc/gitea - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "3000:3000" - "2222:2222" depends_on: - db db: image: docker.io/library/postgres:14 restart: always environment: - POSTGRES_USER=gitea - POSTGRES_PASSWORD=[REDACTED] - POSTGRES_DB=gitea volumes: - ./postgres:/var/lib/postgresql/data ``` ### Database PostgreSQL

GiteaMirror added the issue/needs-feedback label 2025-11-02 11:27:19 -06:00

GiteaMirror closed this issue

2025-11-02 11:27:19 -06:00

GiteaMirror commented

2025-11-02 11:27:20 -06:00

@wxiaoguang commented on GitHub (Sep 25, 2025):

Ask AI (I don't mean everything AI said is right, indeed it shows the root problem)

https://chatgpt.com/share/68d5d2b9-b0ec-8001-948d-0c5873bb74cb

@wxiaoguang commented on GitHub (Sep 25, 2025): Ask AI (I don't mean everything AI said is right, indeed it shows the root problem) https://chatgpt.com/share/68d5d2b9-b0ec-8001-948d-0c5873bb74cb <details> <img width="1512" height="732" alt="Image" src="https://github.com/user-attachments/assets/92f4bbcc-e9fc-4122-9894-3069987496c9" /> </details>

GiteaMirror commented

2025-11-02 11:27:20 -06:00

@petersrinivasan commented on GitHub (Sep 25, 2025):

I already did and it just gives generic crap about how to to work around the issues, as can be seen in your link too. Permissions are already set correctly, given it works for a while until the timeout occurs. The question is why might the timeout break the session instead of just log me out.

I'm using a bind mounted nfs share. Does that sound like an issue y'all have run across in such a configuration?

@petersrinivasan commented on GitHub (Sep 25, 2025): I already did and it just gives generic crap about how to to work around the issues, as can be seen in your link too. Permissions are already set correctly, given it works for a while until the timeout occurs. The question is why might the timeout break the session instead of just log me out. I'm using a bind mounted nfs share. Does that sound like an issue y'all have run across in such a configuration?

GiteaMirror commented

2025-11-02 11:27:20 -06:00

@wxiaoguang commented on GitHub (Sep 26, 2025):

Permissions are already set correctly, given it works for a while until the timeout occurs.

What you see might not be what it is, especially for NFS.

The error open /var/lib/gitea/data/sessions/e/9/e95bdc21b048d4fa: permission denied is from OS&filesystem but not Gitea, so I think Gitea can do nothing in this case.

Can you make sure that you are able to correctly open & write to that file as the Gitea's run user?

IIRC NFS has various problems (see some closed issues)

@wxiaoguang commented on GitHub (Sep 26, 2025): > Permissions are already set correctly, given it works for a while until the timeout occurs. What you see might not be what it is, especially for NFS. The error `open /var/lib/gitea/data/sessions/e/9/e95bdc21b048d4fa: permission denied` is from OS&filesystem but not Gitea, so I think Gitea can do nothing in this case. Can you make sure that you are able to correctly open & write to that file as the Gitea's run user? IIRC NFS has various problems (see some closed issues)

GiteaMirror commented

2025-11-02 11:27:20 -06:00

@wxiaoguang commented on GitHub (Sep 26, 2025):

The question is why might the timeout break the session instead of just log me out.

Because Gitea needs to update the session file, but it fails (due to OS&filesystem error), then it has to treat the session as invalid. Usually for an invalid session, the user gets logged out if no error occurs. (Update) But the session file can't be written, then it causes an internal error.

The root problem is sill that "the session file can't be written correctly"

@wxiaoguang commented on GitHub (Sep 26, 2025): > The question is why might the timeout break the session instead of just log me out. Because Gitea needs to update the session file, but it fails (due to OS&filesystem error), then it has to treat the session as invalid. Usually for an invalid session, the user gets logged out if no error occurs. **(Update) But the session file can't be written, then it causes an internal error.** The root problem is sill that "the session file can't be written correctly"

GiteaMirror commented

2025-11-02 11:27:21 -06:00

@GiteaBot commented on GitHub (Oct 26, 2025):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Oct 26, 2025): We close issues that need feedback from the author if there were no new comments for a month. :tea:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14985