Gitea backup / dump operation is confusing to use

[TheFriendlyCoder]

Description

I wasn't sure if I should classify this as a bug, feature request, or simply a request for clarification in the documentation. I'm going to just outline my expectations wrt using the backup / dump tool, and then describe various things I tried which did not work.

Expectation:
I expected that the gitea dump command would do one of two things: create a dump file in the current working folder, or create a dump file in a specific folder of my choosing based on a command line parameter, something like gitea dump --outputfile=/path/to/file.zip)

Actual:
Running gitea dump with no command line arguments resulted in a "permission denied" error. I then realized that I was running the command from a local users home folder, which likely wasn't accessible to gitea or the default user the app is configured use (ie: git in my case).

So then I tried creating a new folder will full write permission, and owned by the git user:

sudo mkdir /test
sudo chown git:git /test
sudo chmod 777 /test
cd /test
gitea dump

This also resulted in a permission denied error

Given that I had previously experienced some unusual permission issues with the app before, I thought maybe I was hitting something similar here, so I decided to switch to the system /tmp folder and rerun my test:

cd /tmp
gitea dump

To which I was happy to see a successful result: 2023/10/04 00:50:33 cmd/dump.go:423:runDump() [I] Finish dumping in file gitea-dump-1696380633.zip. Then I decided to take a closer look at the generated output file:

$/tmp ls -alh gitea-dump-1696380633.zip
ls: cannot access 'gitea-dump-1696380633.zip': No such file or directory

Ok - so this is weird. First thought: where did the dump file go? I then try sudo find . -name "gitea-dump-1696380633.zip" 2>/dev/null and I find ./snap-private-tmp/snap.gitea/tmp/gitea-dump-1696380633.zip. Ok - this is weird, but still at least it sort of worked. But I'd rather have the file placed in a folder of my choosing, and maybe even named something that I can find more easily.

So next I start looking at the command line parameters for the dump command - maybe there's something in there I can use. I see two options that look like potential candidates: --file and --tempdir.

So I start by testing out the --tempdir option. For kicks I change directories back into my home folder for this test, and do:

cd ~
gitea dump --tempdir /test

and again, more permission errors.... ... so then I try the --file option, as in:

gitea dump --file=/test/output.zip

for which I get yet another permission error: 2023/10/04 01:09:15 cmd/dump.go:166:fatal() [F] Unable to open /test/output.zip: open /est/output.zip: no such file or directory.... Ok - I'm about to give up by now.

Working Solution
For now I've managed to get my backup script sort of working by using the "-" option to redirect the output from the dump operation to stdout, which then allows me to store the output anywhere I want, as in:

gitea dump --file - > /path/to/my/backup.zip

Suggestion
I'd recommend one of the following two courses of action:

1. make the dump command more intuitive to use so it "just works"
2. update the documentation to better explain what the various options are for the dump command, and provide examples of how they are intended to work.

Gitea Version

Gitea version 1.20.5 built with GNU Make 4.3, go1.21.1 : bindata, sqlite, sqlite_unlock_notify, pam, cert

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

git version 2.34.1

Operating System

Ubuntu 22.04.3 LTS

How are you running Gitea?

Command line

Database

SQLite

[lng2020]

Actually, the command is intuitive if the Gitea is built from the source. The problem is about the snap package and its security model. I would recommend installing Gitea from binary, source, or docker. And I agree the doc should be updated.

[TheFriendlyCoder]

So, last night I tried downloading the binary package for Gitea and installing it manually, and pretty much all of my issues disappeared, including those I've described above. So the root cause of many of my problems were directly related to ridiculous permission problems with the snap package.

Given how many problems seem to be specific to that particular package, maybe it would be prudent to have an entire section in the users docs just for snap, warning people about all the things that don't work using that config. :p

Either way, I appreciate the prompt replies and keep up the great work on the project!

[lng2020]

see #27420 (comment)