SFTP Root Directory

When I try to connect to another computer by sftp, I can’t access the / root directory. The example below is from a VM running a Fedora 42 live cd.

In Dolphin’s address bar I type: sftp://daniel@192.168.1222.1. Dolphin takes me directly to /home/Daniel instead of /. When I click on the > next to sftp: 192.168.122.1 it can list the folders in the root directory. However, when I click on sftp: 192.168.122.1 itself it claims to be in the root directory but actually goes to /home/Daniel. Besides creating a symlink to / in my own home directory, is there a way to access it from the path bar?

sftp - the ssh sftp?

If so you need to look at the sshd config on the remote server system.

I doubt that a symlink will work by the way.

It is in the root directory of your user account exactly what you told it to do by logging in using the daniel user for the login. If you want to get the /root/ directory which is the home directory of the root user then you need to enable root login and use that user. Once done with that then perhaps it allows you to change to the / to do your copy as you will have permissions to do so. I know it will allow you to do it over the command line with ssh (scp) using the root user if enabled like I do. Your symbolic link idea will not work as you will still be the user daniel with absolutely no permissions to access a root owned directory.

It’s not /root that I want to go to but / the “root of the filesystem” that I want. Even when I try sftp://192.168.122.1 instead of sftp://daniel@192.168.122.1, I can’t reach / by clicking on 192.168.122.1. It just takes me back to /home/daniel. At least for Cinnamon, Mate, the default for sftp is to go to /. Doing a symlink of ln -s / /home/daniel/rootdir does work, but it’s pretty hacky.

As I said try to use the root user with something like sftp://root@192.168.122.1:/. That should if it works login in as root if enabled in the / directory. Or if you enable the root login with ssh you can just use scp to copy any thing needed to the / of the machine you want.

root@9600k:~# touch test

zeus@9600k:~$ 8400t
Linux 8400t 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jul 17 20:55:23 2025 from 192.168.0.101
seeder1@8400t:~$ su
Password: 
root@8400t:/home/seeder1# cd
root@8400t:~# cd /
root@8400t:/# ls -l
total 2097220
      0 lrwxrwxrwx   1 root root          7 Feb 27 03:06 bin -> usr/bin/
      4 drwxr-xr-x   4 root root       4096 Jun 28 10:02 boot/
      0 drwxr-xr-x  15 root root       3200 Jun 28 10:03 dev/
      4 drwxr-xr-x  83 root root       4096 Aug  4 19:32 etc/
      4 drwxr-xr-x   3 root root       4096 Feb 27 03:12 home/
      0 lrwxrwxrwx   1 root root         30 Jun 28 09:58 initrd.img -> boot/initrd.img-6.1.0-37-amd64
      0 lrwxrwxrwx   1 root root         30 Jun 28 09:58 initrd.img.old -> boot/initrd.img-6.1.0-35-amd64
      0 lrwxrwxrwx   1 root root          7 Feb 27 03:06 lib -> usr/lib/
      0 lrwxrwxrwx   1 root root          9 May 18  2020 lib32 -> usr/lib32
      0 lrwxrwxrwx   1 root root          9 Feb 27 03:06 lib64 -> usr/lib64/
      0 lrwxrwxrwx   1 root root         10 May 18  2020 libx32 -> usr/libx32
     16 drwx------   2 root root      16384 Oct  1  2024 lost+found/
      4 drwxr-xr-x   3 root root       4096 Feb 27 03:06 media/
      4 drwxr-xr-x   2 root root       4096 May 18  2020 Media_Haswell/
      4 drwxr-xr-x   2 root root       4096 Feb 27 03:06 mnt/
      4 drwxr-xr-x   3 root root       4096 Feb 27 07:38 opt/
      0 dr-xr-xr-x 210 root root          0 Jun 28 10:03 proc/
      4 drwx------   8 root root       4096 Feb 28 02:33 root/
      0 drwxr-xr-x  14 root root        620 Aug  5 02:39 run/
      0 lrwxrwxrwx   1 root root          8 Feb 27 03:06 sbin -> usr/sbin/
      4 drwxr-xr-x   2 root root       4096 Feb 27 03:06 srv/
2097156 -rw-------   1 root root 2147483648 Oct  1  2024 swapfile
      0 dr-xr-xr-x  13 root root          0 Jun 28 10:03 sys/
      4 drwxrwxrwt   2 root root       4096 Aug  3 03:18 tmp/
      4 drwxr-xr-x  12 root root       4096 Feb 27 03:06 usr/
      4 drwxr-xr-x  12 root root       4096 Feb 27 04:12 var/
      0 lrwxrwxrwx   1 root root         27 Jun 28 09:58 vmlinuz -> boot/vmlinuz-6.1.0-37-amd64
      0 lrwxrwxrwx   1 root root         27 Jun 28 09:58 vmlinuz.old -> boot/vmlinuz-6.1.0-35-amd64
root@9600k:~# scp test root@8400t.lan:/
test                                          100%    0     0.0KB/s   00:00   

root@8400t:/# ll
total 2097220
      0 lrwxrwxrwx   1 root root          7 Feb 27 03:06 bin -> usr/bin/
      4 drwxr-xr-x   4 root root       4096 Jun 28 10:02 boot/
      0 drwxr-xr-x  15 root root       3200 Jun 28 10:03 dev/
      4 drwxr-xr-x  83 root root       4096 Aug  4 19:32 etc/
      4 drwxr-xr-x   3 root root       4096 Feb 27 03:12 home/
      0 lrwxrwxrwx   1 root root         30 Jun 28 09:58 initrd.img -> boot/initrd.img-6.1.0-37-amd64
      0 lrwxrwxrwx   1 root root         30 Jun 28 09:58 initrd.img.old -> boot/initrd.img-6.1.0-35-amd64
      0 lrwxrwxrwx   1 root root          7 Feb 27 03:06 lib -> usr/lib/
      0 lrwxrwxrwx   1 root root          9 May 18  2020 lib32 -> usr/lib32
      0 lrwxrwxrwx   1 root root          9 Feb 27 03:06 lib64 -> usr/lib64/
      0 lrwxrwxrwx   1 root root         10 May 18  2020 libx32 -> usr/libx32
     16 drwx------   2 root root      16384 Oct  1  2024 lost+found/
      4 drwxr-xr-x   3 root root       4096 Feb 27 03:06 media/
      4 drwxr-xr-x   2 root root       4096 May 18  2020 Media_Haswell/
      4 drwxr-xr-x   2 root root       4096 Feb 27 03:06 mnt/
      4 drwxr-xr-x   3 root root       4096 Feb 27 07:38 opt/
      0 dr-xr-xr-x 209 root root          0 Jun 28 10:03 proc/
      4 drwx------   8 root root       4096 Feb 28 02:33 root/
      0 drwxr-xr-x  14 root root        620 Aug  5 02:40 run/
      0 lrwxrwxrwx   1 root root          8 Feb 27 03:06 sbin -> usr/sbin/
      4 drwxr-xr-x   2 root root       4096 Feb 27 03:06 srv/
2097156 -rw-------   1 root root 2147483648 Oct  1  2024 swapfile
      0 dr-xr-xr-x  13 root root          0 Jun 28 10:03 sys/
      0 -rw-r--r--   1 root root          0 Aug  5 02:40 test
      4 drwxrwxrwt   2 root root       4096 Aug  3 03:18 tmp/
      4 drwxr-xr-x  12 root root       4096 Feb 27 03:06 usr/
      4 drwxr-xr-x  12 root root       4096 Feb 27 04:12 var/
      0 lrwxrwxrwx   1 root root         27 Jun 28 09:58 vmlinuz -> boot/vmlinuz-6.1.0-37-amd64
      0 lrwxrwxrwx   1 root root         27 Jun 28 09:58 vmlinuz.old -> boot/vmlinuz-6.1.0-35-amd64

There you can see I first create the test file on the 9600k machine. Login to the 8400t machine with a passwordless key, use su to becone root user change to the / directory do a directory listing. Then copy the test file using scp from the 9600k machine to the /of the 8400t as the directory show it now there. Using the tools at hand a straight up copy of the file is done with no messing around with a gui needed.

Using the root user may be viable for a VM to host scenario, but this won’t work for a multi user home server scenario. Even with public key authentication, having everyone now log in as root is not great from a security standpoint. (Not that I’d forcibly convert eveyone to KDE, but as the “official sysadmin” people take my recommendations.)

Also, having to use the command line to scp files where, I could previously use the gui in Cinnamon to move cell phone pictures to /home/shared/pictures/daniel\ pixel7 would be a pretty big downgrade in experience.

This is correct behaviour, but…

I’m pretty sure just a month or two ago typing a / at the end (as in sftp://daniel@192.168.1222.1/ would have brought you to the root. This does not work anymore. Neither is it possible to use up to get there. The fish:// protocol is affected in the same way.

I’d say this is a regression and should be reported as a bug. Did you already do this?

I didn’t yet. I thought maybe I was doing something wrong or missed a setting somewhere. Will do. Thanks for confirming.

I’m having the same issue after upgrading from 6.13 to 6.16, with both fish and sftp. What is interesting is that even if it shows the user home directory, newly added/created file/dir will be placed in root /.

I filed a bug yesterday. Someone already found out what the problem is: 507922 – Dolphin SFTP Cannot Reach Root Directory

Simplified the problematic commit down to this patch. Recompiled in fedora and it works again!

--- a/src/core/kcoredirlister.cpp	2025-08-06 21:29:26.466783775 -0700
+++ b/src/core/kcoredirlister.cpp	2025-08-06 21:30:18.599257301 -0700
@@ -2819,16 +2819,7 @@
 
 QUrl KCoreDirListerCache::cleanUpTrailingSlash(const QUrl &url) const
 {
-    // Url is just a scheme or it's local, we can return it with regular clean
-    if (url.path().isEmpty() || url.isLocalFile()) {
-        return url.adjusted(QUrl::StripTrailingSlash);
-    }
-    QString cleanedPath = url.adjusted(QUrl::StripTrailingSlash).toString();
-    if (cleanedPath.endsWith(QLatin1Char('/'))) {
-        cleanedPath.chop(1);
-    }
-
-    return QUrl(cleanedPath);
+		return url.adjusted(QUrl::StripTrailingSlash);
 }
 
 QList<KCoreDirLister *> KCoreDirListerCacheDirectoryData::listersByStatus(ListerStatus status) const

Should be fixed in KF 6.17, scheduled to release August 8th.