Permission denied errors after upgrade to 1.16.5 / fails to start

[catinello]

Description

After upgrading to 1.16.5 my installation was not coming back up. I'm receiving those errors (see GIST for Log and Doctor output), even though the permissions are correct. Switching to the gitea user allows me to create directories and files in the given paths.

2022/04/10 20:20:47 routers/init.go:131:GlobalInitInstalled() [I] SQLite3 support is enabled
2022/04/10 20:20:47 ...eue/queue_wrapped.go:73:setInternal() [W] [Attempt: 1] Failed to create queue: unique-level for repo-archive cfg: queue.LevelUniqueQueueConfiguration{ByteFIFOQueueConfiguration:queue.ByteFIFOQueueConfiguration{WorkerPoolConfiguration:queue.WorkerPoolConfiguration{QueueLength:20, BatchLength:20, BlockTimeout:1000000000, BoostTimeout:300000000000, BoostWorkers:1, MaxWorkers:5}, Workers:0, Name:"repo-archive-level", WaitOnEmpty:false}, DataDir:"data/data/queues/common", ConnectionString:"", QueueName:""} error: unable to open level db at data/data/queues/common: mkdir data: permission denied
2022/04/10 20:20:47 routers/common/db.go:20:InitDBEngine() [I] Beginning ORM engine initialization.
2022/04/10 20:20:47 ...eue/queue_wrapped.go:73:setInternal() [W] [Attempt: 1] Failed to create queue: level for push_update cfg: queue.LevelQueueConfiguration{ByteFIFOQueueConfiguration:queue.ByteFIFOQueueConfiguration{WorkerPoolConfiguration:queue.WorkerPoolConfiguration{QueueLength:20, BatchLength:20, BlockTimeout:1000000000, BoostTimeout:300000000000, BoostWorkers:1, MaxWorkers:5}, Workers:0, Name:"push_update-level", WaitOnEmpty:false}, DataDir:"data/data/queues/common", ConnectionString:"", QueueName:""} error: unable to open level db at data/data/queues/common: mkdir data: permission denied
2022/04/10 20:20:47 ...eue/queue_wrapped.go:73:setInternal() [W] [Attempt: 1] Failed to create queue: level for mail cfg: queue.LevelQueueConfiguration{ByteFIFOQueueConfiguration:queue.ByteFIFOQueueConfiguration{WorkerPoolConfiguration:queue.WorkerPoolConfiguration{QueueLength:20, BatchLength:20, BlockTimeout:1000000000, BoostTimeout:300000000000, BoostWorkers:1, MaxWorkers:5}, Workers:0, Name:"mail-level", WaitOnEmpty:false}, DataDir:"data/data/queues/common", ConnectionString:"", QueueName:""} error: unable to open level db at data/data/queues/common: mkdir data: permission denied
2022/04/10 20:20:47 ...eue/queue_wrapped.go:73:setInternal() [W] [Attempt: 1] Failed to create queue: level for notification-service cfg: queue.LevelQueueConfiguration{ByteFIFOQueueConfiguration:queue.ByteFIFOQueueConfiguration{WorkerPoolConfiguration:queue.WorkerPoolConfiguration{QueueLength:20, BatchLength:20, BlockTimeout:1000000000, BoostTimeout:300000000000, BoostWorkers:1, MaxWorkers:5}, Workers:0, Name:"notification-service-level", WaitOnEmpty:false}, DataDir:"data/data/queues/common", ConnectionString:"", QueueName:""} error: unable to open level db at data/data/queues/common: mkdir data: permission denied
2022/04/10 20:20:47 routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #1/10...
2022/04/10 20:20:47 cmd/web.go:153:runWeb() [I] PING DATABASE sqlite3
2022/04/10 20:20:47 cmd/web.go:153:runWeb() [W] Table email_address Column lower_email db nullable is true, struct nullable is false
2022/04/10 20:20:47 routers/init.go:137:GlobalInitInstalled() [I] ORM engine initialization successful!

This kind of output loops forever.

If you need further information, please let me know.

Gitea Version

1.16.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/catinello/910df81c3dfa131fe347f3a528fa8966

Screenshots

No response

Git Version

2.35.1

Operating System

Void Linux

How are you running Gitea?

Packaged gitea version as a running service. https://github.com/void-linux/void-packages/tree/master/srcpkgs/gitea

Database

SQLite

[techknowlogick]

It is recommended you use absolute paths because error: unable to open level db at data/data/queues/common: mkdir data: permission denied is looking for data/data/.... The mkdir error is coming from the OS.

[catinello]

Thank you @techknowlogick that fixed the issue.

Setting APP_DATA_PATH to an absolute path.
APP_DATA_PATH = /var/lib/gitea/data

Is there something planned to add an automatic fix or alert to check for absolute paths? I didn't think of path problems, because the gitea doctor did not alert on the check and it worked without issue on the versions before.

$ gitea doctor --all --fix --config /etc/gitea.conf -C /var/lib/gitea/custom/ -w /var/lib/gitea/
[1] Check paths and basic configuration

• [I] Configuration File Path: "/etc/gitea.conf"
• [I] Repository Root Path: "/var/lib/gitea/repositories"
• [I] Data Root Path: "data"
• [I] Custom File Root Path: "/var/lib/gitea/custom/"
• [I] Work directory: "/var/lib/gitea/"
• [I] Log Root Path: "/var/log/gitea"
  OK
  ...

[ericonr]

@catinello would you mind reopening this issue? I believe this was a regression and should at least be documented. I was just bit by it myself.

gitea/custom/conf/app.example.ini

Line 227 in 8720f87

;APP_DATA_PATH = data

The example config still has it as a relative path, too.

I see you use the Void package, another solution I found for it was to cd into $HOME

[silentcodeg]

@ericonr from which Gitea version did you upgrade?

[catinello]

Since @zeripath did open a new issue already. I don't think re-opening is still needed? @ericonr

[singuliere]

See https://hostea.org/blog/path-not-found/ for a detailed explanation of this issue.

[ericonr]

@silentcodeg I updated from 1.15.8