Can't backup - permissions problems

Installation is currently Gitea 1.16.8, native install on Ubuntu server (no containers). Installed per the instructions and all works fine.

However, following the instructions (and various threads) on backing up I just can’t make it work - the backup instructions are simply:

Switch to the user running Gitea: su git. Run ./gitea dump -c /path/to/app.ini in the Gitea installation directory.

So, I do exactly that and this is the result:

$ systemctl stop gitea
$ cd /usr/local/bin/
$ sudo -u git gitea dump -c /etc/gitea/app.ini
2024/10/17 07:54:00 ...dules/setting/log.go:287:newLogService() [I] Gitea v1.16.8 built with GNU Make 4.1, go1.18.2 : bindata, sqlite, sqlite_unlock_notify
2024/10/17 07:54:00 ...dules/setting/log.go:334:newLogService() [I] Gitea Log Mode: Console(Console:)
2024/10/17 07:54:00 ...dules/setting/log.go:250:generateNamedLogger() [I] Router Log: Console(console:)
2024/10/17 07:54:00 ...les/setting/cache.go:78:newCacheService() [I] Cache Service Enabled
2024/10/17 07:54:00 ...les/setting/cache.go:93:newCacheService() [I] Last Commit Cache Service Enabled
2024/10/17 07:54:00 ...s/setting/session.go:75:newSessionService() [I] Session Service Enabled
2024/10/17 07:54:00 ...s/storage/storage.go:171:initAttachments() [I] Initialising Attachment storage with type: 
2024/10/17 07:54:00 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/attachments
2024/10/17 07:54:00 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type: 
2024/10/17 07:54:00 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/avatars
2024/10/17 07:54:00 ...s/storage/storage.go:183:initRepoAvatars() [I] Initialising Repository Avatar storage with type: 
2024/10/17 07:54:00 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/repo-avatars
2024/10/17 07:54:00 ...s/storage/storage.go:177:initLFS() [I] Initialising LFS storage with type: 
2024/10/17 07:54:00 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/lfs
2024/10/17 07:54:00 ...s/storage/storage.go:189:initRepoArchives() [I] Initialising Repository Archive storage with type: 
2024/10/17 07:54:00 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/repo-archive
Unable to open gitea-dump-1729151640.zip: open gitea-dump-1729151640.zip: permission denied
2024/10/17 07:54:00 cmd/dump.go:149:fatal() [F] Unable to open gitea-dump-1729151640.zip: open gitea-dump-1729151640.zip: permission denied

I have tried various suggestions found online including passing -work-path /tmp/ and running from inside /tmp/ instead to no success - in that case I get a different error but still permisisons related:

2024/10/16 15:15:07 cmd/dump.go:315:runDump() [I] Packing data directory.../tmp/data
Failed to include log: open /var/log/kern.log.3.gz: permission denied
2024/10/16 15:15:08 cmd/dump.go:149:fatal() [F] Failed to include log: open /var/log/kern.log.3.gz: permission denied

I wanted to check I’m not missing something or doing something wrong here before I start messing with permissions etc.

Still no solution to this - permissions seem correct, advice online to add paths to app.ini (APP_DATA_PATH = /var/lib/gitea/data/) make no difference.

Gitea / user ‘git’ has access / permissions / ownership of all the folders it needs as far as I can find.

Here’s what happens if I try to backup now:

Current gitea verison is: 1.16.8

Backing up...

/usr/local/bin/gitea dump -c /etc/gitea/app.ini
2025/03/21 11:45:46 ...dules/setting/log.go:287:newLogService() [I] Gitea v1.16.8 built with GNU Make 4.1, go1.18.2 : bindata, sqlite, sqlite_unlock_notify
2025/03/21 11:45:46 ...dules/setting/log.go:334:newLogService() [I] Gitea Log Mode: Console(Console:)
2025/03/21 11:45:46 ...dules/setting/log.go:250:generateNamedLogger() [I] Router Log: Console(console:)
2025/03/21 11:45:46 ...les/setting/cache.go:78:newCacheService() [I] Cache Service Enabled
2025/03/21 11:45:46 ...les/setting/cache.go:93:newCacheService() [I] Last Commit Cache Service Enabled
2025/03/21 11:45:46 ...s/setting/session.go:75:newSessionService() [I] Session Service Enabled
2025/03/21 11:45:46 ...s/storage/storage.go:171:initAttachments() [I] Initialising Attachment storage with type: 
2025/03/21 11:45:46 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/attachments
2025/03/21 11:45:46 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type: 
2025/03/21 11:45:46 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/avatars
2025/03/21 11:45:46 ...s/storage/storage.go:183:initRepoAvatars() [I] Initialising Repository Avatar storage with type: 
2025/03/21 11:45:46 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/repo-avatars
2025/03/21 11:45:46 ...s/storage/storage.go:177:initLFS() [I] Initialising LFS storage with type: 
2025/03/21 11:45:46 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/lfs
2025/03/21 11:45:46 ...s/storage/storage.go:189:initRepoArchives() [I] Initialising Repository Archive storage with type: 
2025/03/21 11:45:46 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /usr/local/bin/data/repo-archive
Unable to open gitea-dump-1742557546.zip: open gitea-dump-1742557546.zip: permission denied
2025/03/21 11:45:46 cmd/dump.go:149:fatal() [F] Unable to open gitea-dump-1742557546.zip: open gitea-dump-1742557546.zip: permission denied

I really would appreciate some help here, I’m not new to Linux but this is just frustratingly fiddly.

The issue is the user “git” does have permissions to write to the PWD and it is likely to be owned by the user you execute sudo as

Say your user is “foo” and you are in $HOME ( eg /home/foo), using sudo permits executing the dump as the correct user, got, but this user cannot write to /home/foo.

You need to change directory to where the user git has wrote access. Or … Use the --file arguement to set the directory/filename explicitly

1 Like