How are you supposed to start applications as root?

Hi there,

okay my questions sound newbish please excuse me for that.

I know it’s dangerous to run applications as root…

But when I need to I started them e.g. in krunner with kdesu $applicationname

Now I am experiencing a strange behavior and don’t know what’s going on:

After I started kdesu dolphin to make some changes and closed it. Every application which is started with krunner starts with root privileges (e.g. konsole).
This was not happening in the past. According to it should be possible to stop the kdesu deamon with kdesu -t. This did nothing. Only killing the kdesud process seemed to help.

This seems not to happen every time.

So my questions: Am I the only one with this “bug”?
How do you start applications as root if you need to?


Read this:

This is probably the important bit which so additional details may help;

After I started kdesu dolphin to make some changes and closed it.

That would indicate you have likely changed the ownership to root user… hence the need for more info…

And indeed, you may say “But when I need to I started them”, it is doubtful that you realy need. But when you do not explain…, we are not clairvoyant.

And like @malcomlewis hints at, you can do more damage with using root when you shouldn’t in a second then you can repair in hours. :frowning:

Well I did like I wrote exactly what is described here
-> run ALT+F2 kdesu dolphin

Sorry but I don’t know how your link should help?

What kind of info could that be?

Just to add this: I did not check the box to remember the password.

That would be the task you were performing in dolphin as root user… as in what did you do? :wink:

Ah sorry didn’t think that this is important.

I formated a harddrive and when you mount them afterward they usually belong to root. So just started dolphin as root and gave my user the ownership of the harddrive.

In the future I would recommend you use YaST Partitioner for that :wink: So how did you change the ownership of the drive, did you click on the partition, or the drive itself?

Open a terminal window (konsole), can you show the output from the following;


I used the Yast Partitioner.

That’s an external drive which is encrypted …
And no I just went to the root directory of this drive, ALT+Return second tab → there I changed the user from root to me.
The drive is connected via e-sata. (It is the device sdc)

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0 931,5G  0 disk  
├─sda1                                          8:1    0   500M  0 part  /boot/efi
├─sda2                                          8:2    0    50G  0 part  /srv
└─sda3                                          8:3    0 880,7G  0 part  
  └─home                                      254:0    0 880,7G  0 crypt /home
sdb                                             8:16   0   5,5T  0 disk  
├─sdb1                                          8:17   0   5,4T  0 part  
│ └─tank                                      254:1    0   5,4T  0 crypt /mnt/tank
└─sdb2                                          8:18   0 100,6G  0 part  
sdc                                             8:32   0   3,7T  0 disk  
└─sdc1                                          8:33   0   3,6T  0 part  
  └─luks-553bf341-3a7e-41ce-b28f-1b5155ac9bf2 254:2    0   3,6T  0 crypt /run/media/user/9fdc5796-9899-446d-9323-1c774c66dc32
sr0                                            11:0    1  1024M  0 rom  


sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=8151512k,nr_inodes=2037878,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
/dev/sda2 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=1522,subvol=/@/.snapshots/989/snapshot)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17690)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
/dev/sda2 on /.snapshots type btrfs (rw,relatime,ssd,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,ssd,space_cache,subvolid=265,subvol=/@/boot/grub2/i386-pc)
/dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,ssd,space_cache,subvolid=264,subvol=/@/boot/grub2/x86_64-efi)
/dev/sda2 on /tmp type btrfs (rw,relatime,ssd,space_cache,subvolid=260,subvol=/@/tmp)
/dev/sda2 on /usr/local type btrfs (rw,relatime,ssd,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/sda2 on /opt type btrfs (rw,relatime,ssd,space_cache,subvolid=263,subvol=/@/opt)
/dev/sda2 on /root type btrfs (rw,relatime,ssd,space_cache,subvolid=262,subvol=/@/root)
/dev/sda2 on /var type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@/var)
/dev/sda2 on /srv type btrfs (rw,relatime,ssd,space_cache,subvolid=261,subvol=/@/srv)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mapper/home on /home type ext4 (rw,relatime)
/dev/mapper/tank on /mnt/tank type ext4 (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1633944k,mode=700,uid=1000,gid=100)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
vmware-vmblock on /run/vmblock-fuse type fuse.vmware-vmblock (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
/dev/mapper/luks-553bf341-3a7e-41ce-b28f-1b5155ac9bf2 on /run/media/user/9fdc5796-9899-446d-9323-1c774c66dc32 type xfs (rw,nosuid,nodev,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota,uhelper=udisks2)

The link is a direct answer to your question as posted in the thread title.

But IMHO the question is not so much how to start an application as root, but when things are going wrong after that, the qiestion is what one then did with that application.

But I see that you are alread trying to explain that in detail.

That looks ok to me, so what where you doing previously with kdesu?

Likely the easiest way is to boot from a previous snapshot and revert to that and move forward again…

Have a read here first:

As I said I did just the change of the ownership and closed dolphin afterwards. And I did not use kdesu this day before.

After manually killing the kdesud process everything seems to be normal again.

I couldn’t reproduce the issue again right now but as I said this happened several times in the past weeks. (I had to reformat some drives… so the operation was always the same).

Last time I didn’t care much and I was going to bed anyway and after a reboot everything was behaving normal.
Today I wanted to resolve this without a reboot and was wondering if I was doing it wrong.

The only way to start an application via ALT+F2 after this glitch with my user was to type kdesu -u my_username applicationname.
Applications launched via the KDE menu were started with my user.

Every Tumbleweed user should know snapper :wink: Which is super handy but I am not sure a rollback will help since this happened several times in the last weeks.

As this does not seem to be a general issue of my “workflow” could this be a bug? Where would you report it? I mean is it a KDE, openSUSE … bug?

I would suggest creating a test user and login as that user, does the issue duplicate?

BTW, I do not see the need to use Alt-F2 and what all when there is an item in the Start menu > System > File Manger - Super User Mode. It is in my KDE start menu and as I am not aware that I put it there myself, it is put there by default.

The example is mentioned in the SDB I linked to (not litteraly, but it suggest to look for items like that).

Ok I am going to try that.

Okay, yes and you can launch this “dolphin super user” entry also from ALt+F2 (it links to the same entries in the menu afaik). To be honest I am using ALT+F2 or ALT+Space most of the time to launch applications. It’s much faster for me.

Thank you guys.

Today’s modern Linux supports mounting drives a number of ways.
Dolphin supports mounting drives (particularly external, attached drives like external USB) dynamically (No need to define the drive in fstab for example).

You will need elevated permissions to execute filesystem and partitioning changes to the drive…


I concur with Henk,
If you’re running KDE, simply launching Dolphin in Super User mode is the most direct way to run the file manager with root permissions.

Besides the methods described in this reference,
I have found for awhile now at least for the applications I launch there is no need to run kdesu or gnomesu to launch even graphical apps with root permissions,
I simply create an elevated console using “su” and then from that launch whatever app by its command.

Note the warning in the reference which likely applies to running anything with root permissions, it’s likely all safeguards have been removed so if your app removes something undocumented, unintentionally or by stupid mistake, you could do serious or hidden damage to your system.