Naming convention change

Hi there folks.

I note with encouragement that in recent releases you’ve started to shift the use of the user root in software packages towards using dietpi or something instead.

I got my Odroid HC2 last Spring and stuck DietPi on it straight away, putting all my software in place in the space of a few weeks. For users who already set their software up using DietPi’s install tools before the move away from using root happened, what would the devs recommend as a non-headache-inducing method for tackling the switch over to non-root users for software we’ve already got running (services, programs…) and want to get stuff properly locked down/just feel a bit obsessive about everything using the same naming?

I’m up for a bit of housekeeping now that my box has been bedded in for the good part of a year as long as it’s not frustrating and too time-consuming and am pretty proficient on the commandline.


The dietpi user exists already as long as I am contributing to DietPi, but with v6.12 we switched several software titles to use their own run user instead of root.

So e.g. Sonarr runs as user sonarr, MPD as mpd etc. see a list of affected software titles here:
Some followed in later DietPi versions.

Most of these run as group dietpi, respectively their user is member of this group, which allows e.g. media players to access downloads from Sonarr/Radarr and allow them again to access torrent downloaders and such.

So they run as their own user but most share dietpi group permissions for cross-access.

These changes are applied automatically during dietpi-update, so no need to manually apply. If you have a pre-v6.12 system, create a dietpi-backup for sure and be prepared for some manual adjustments. There are then (at least) 10 version steps to be done until current v6.21, which raises the risk of update issues. However I would assist quickly if you write here.

Michalng, thanks for offering to check.

These are the services I’ve got running as root now, that I’m not sure about: transmission-daemon, fail2ban, smbd/nmbd and dropbear.

Appreciate the offer to advice, thanks.

dietpi is actually up-to-date, no need for concern there.

Dropbear, fail2ban and the Samba server must run as root, not chance they can do what they are made for when running as underprivileged user.

Ah jep indeed we ran Transmission as root with an own systemd unit in the past but now simply use the systemd unit provided by the Debian APT package where Transmission then runs as “debian-transmission” user.

Please check:

rm -f /etc/systemd/system/transmission-daemon.service
systemctl daemon-reload
systemctl cat transmission-daemon

If it contains User=debian-transmission.

If not (or it throws some error), try:

G_AGI --reinstall transmission-daemon
systemctl cat transmission-daemon

Check if it changed.

If still not try:

rm /lib/systemd/system/transmission-daemon.service
G_AGI --reinstall transmission-daemon

We did two changes to the Transmission installer since v6.9 so it depends on the age of your image which of the above is required. So do not, these should apply the the correct user failsafely.

Ah, brilliant. Done. transmission-daemon is now running as debian-transmission user. Good to know the other services are set up right.

Thanks for your help with this.