Hi,
I’m unfortunately still not really proficient in Linux and have trouble setting up Gitea:
After adding Gitea via dietpi-software, I am presented with the initial configuration screen (IP:3000). I changed the following settings:
“Database Settings”:
Username: phpmyadmin
Password: [phpmyadmin password]
General Settings:
Repository Root Path: /mnt/vhd/gitea/data/gitea-repositories
GIT LFS Root Path: /mnt/vhd/gitea/data/lfs
Run as Username: git
SSH Server Domain: localhost
Log Path: /mnt/vhd/gitea/log
Before commiting the changes, I first created the user with this command:
sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' --group --disabled-password --home /home/git git
as found here. Secondly, I created a directory as root with
mkdir /mnt/vhd/gitea
and then changed the owner (hopefully) with
chown git gitea/
(after having navigated to /mnt/vhd.
However, I get the following error:
The repository root path is invalid: mkdir /mnt/vhd/gitea/data: permission denied
Furthermore, I wonder if these settings are really secure. Can’t somebody just log in with the git account externally?
Thank you in advance and I’m sorry if these are stupid questions. 
Edit: I got it working after changing the “Run as Username” back to “dietpi” (and the folder permissions), though I don’t quite understand why.
Gitea has it’s own database user (as all software that uses MariaDB, provide by DietPi-Software). Please check our docs, the “First run setup” tab: https://dietpi.com/docs/software/cloud/#gitea
The database password is btw not always “dietpi”, but the global software password you either set via dietpi.txt before first boot, during firstrun setup or via dietpi-config, and only defaults to “dietpi”. I’ll fix that 
.
I guess OP tried to create a new OS user to have Gitea running under this user. Usually it should have been enough to add these new user to user group
dietpi
This was addressing:
“Database Settings”:
Username: phpmyadmin
Password: [phpmyadmin password]
which is basically wrong, may work, when phpMyAdmin is installed, but not recommended to not grant Gitea admin permissions over the whole MariaDB server.
But indeed I somehow missed to read on. Not sure what the goal is to change the user, also AFAIK it is not possible like this as Gitea runs as user “dietpi”, which cannot fork child processes as “git” user. So if for some reason a different user is wanted, the systemd unit itself needs to be changed:
dietpi-services > gitea > Edit > uncomment and changed User=dietpi to User=git and the Environment and WorkingDirectory accordingly. Not sure how far they are overridden by the settings chosen within the setup wizard.
CTRL+O to save, CTRL+X to quit the editor. When exiting dietpi-services, the service will restart automatically.
I tried this and failed:
And I have already a git setup with user pi in /home/pi/git. So am I not suppose to let Gitea point there in Repository Root Path?
The global password is not working for the database setting together with the user gogs. Or must I add the user to the system with adduser?
The database user is gitea matching the database and software name. gogs is used for Gogs 
.
Services have issues accessing the login user’s home directory, already as of file permissions, but also systemd sandbox-wise. I suggest to leave it the default within the gitea service user’s home directory.
1 Like
probably we should add the user to be used to our online docs?
1 Like
Now I have installed it manually with user git. It was a horrible permission hell, as you probably can think of. But now it works.
With the next problem or pi, I will try the updated documentation ;-).
I am not sure if it was that easy, because I really tried it out, even with gitea, git, with password “password” , with root password as described, but none of the many things I tried out worked.
I think I did a mixture between your config and the description here and created a systemd service:
raspberry pi gitea install
Obviously I have created a group git and add this group also to root. Also I created manual all necessary root pathes with group access rights like the /usr/local/bin/data path and so on. It was a very cruel iterative way of rebooting, looking at the log (which I put directly in /home/git/gitea-log, and the gitea itself lies now in /home/git/git, which was the copied git root of my git repos. Finally I managed to import all repos manually by migrating them. I thought first copying would be enough, but wasn’t . Finally I removed the false copies in /home/git/git. I would now after my experience, name it instead gitea- it was such a waste of time, compared to the efficiency of my work, but at least now it works.
So why I am telling you? Because I think, there is some lacking in the install description of dietpi which I did not manage to find out, but it was surely not the “gogs” user.
There is no need to do anything manually. Using dietpi-software will install everything end-to-end. Just install the software and follow the first run setup instructions. Basically the only thing to be done is to enter the database password. done. I just tested it without issues.
I don’t know. I have spent yesterday with a complete new image. I did everything according to the docs. Only if the docs did not wori, I derive.
I had a lot of issues,first with xrdp, than with gitea. I installed with dietpi-software, believe me. I did not want it to be such complicated. It was my free day, and my task was to finish my flask service client. Unfortunately I thought I could solve these minor issues, like the high cpu load and the deviations from the behavior I described compared to the behaviordescribed here. I blatantly failed, but still don’t know the reason…
Hmm, the guide sets up everything differently, also the database. I’m not sure how it looks like now. Basically it’s either using a 3rd party guide or using dietpi-software only (which does work well). The systemd service might also simply use the wrong config, depending on it’s content, where it is stored and whether you installed it before or after using dietpi-software.
However, so I understand correctly that it works now?
Another hit: mysql_secure_installation is not increasing, but decreasing the MariaDB security, and it breaks further dietpi-software database creations when the root password is set. All it’s steps are obsolete, and setting a root password removes the default unix authentication plugin which allows logins from a root user shell session only (no other UNIX user can login as root database user). With a password, any other UNIX user can try brute-forcing the database. Remote logins are disabled for all users by default, no anonymous user or test database exist. Not sure why Debian keeps shipping this relic, and so many guides keep using it 
.
1 Like
I would really like to help and do it once again, but as it works now and I already spent a lot of unplanned time.
One ThoughT: could it be, that if the password has characters like ‘&’ inside, that it maybe has problems with the password config in gitea? Because finally I use a user git with a password not containing ‘&’ but ‘#’. The database is set up with a user gitea, table gitea and the granted full access to it.
I also admit that I first installed git-core…
Special characters could be a problem, but I’m not sure which one. MariaDB AFAIK can deal with nearly everything, but Gitea probably not.
Would be actually nice to find out about this and add it to our documentation .
1 Like
It seems with backticks or triple double quotes the database password can be escaped to contain special characters ; and # in the config file: Config Cheat Sheet - Docs
The question is whether the same is either required when typing it into the install form on web UI or done automatically when those characters are found in the input (would be neat). You could check the app.ini about it when you use either one of these characters.
So I installed gitea and mariadb through dietpi-software, the database exists, but the user cannot authenticate:
Testing access with sudo su -l gitea -s /bin/bash:
gitea@DietPi:~$ mysql
ERROR 1045 (28000): Access denied for user 'gitea'@'localhost' (using password: NO)
Also tested password dietpi.
EDIT 2: Okay, I used my root password and that worked. I think the password was set initially when I tried to use my root user with its password, but it failed because the root user didn’t work.
In the end, I changed the password for the user gitea via mysql and updated my gitea conf. Thx and bye.
It should be the global software password and is set automatically during installation. See our online docs Cloud and Backup Systems Software Options - DietPi.com Docs
Sometimes this is similar to root user.
Guess I misunderstood the “software password”. This makes perfect sense and yes, it is the same. The installer should state the “software password” might be stored without encryption on the system, so that’s why it’s not recommend to use the root password. I changed it with dietpi-config, thanks.
