How to set up to keep KDE from listing volumes that are not in fstab

Hi all!

I now have a triple boot desktop - openSUSE 13.1, openSUSE 13.2, win7 - all on one 2TB hard disk.

parted -l now gives:

Model: ATA ST2000NM0033-9ZM (scsi)                                                                                          
Disk /dev/sda: 2000GB                                                                                                       
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  106MB   105MB   primary   ntfs            type=07
 2      106MB   429GB   429GB   extended                  boot, lba, type=0f
 5      107MB   17.3GB  17.2GB  logical   linux-swap(v1)  type=82
 6      17.3GB  51.6GB  34.4GB  logical   ext3            type=83
 7      51.6GB  86.0GB  34.4GB  logical   ext4            type=83
 8      86.0GB  258GB   172GB   logical   ext3            type=83
 9      258GB   429GB   172GB   logical                   type=83
 3      429GB   704GB   275GB   primary   ntfs            type=07
 4      704GB   2000GB  1296GB  primary   ntfs            type=07


Model: Linux device-mapper (crypt) (dm)
Disk /dev/mapper/cr_home: 172GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End    Size   File system  Flags
 1      0.00B  172GB  172GB  ext4

All openSUSE partitions (/dev/sda5 to /dev/sda9) are logical drives within an extended partition (/dev/sda2).

openSUSE13.2 was the last one installed, in /dev/sda7 (mounted /) and in /dev/sda9 (encrypted volume mounted /home).

I had trouble during rebooting 13.1 the first time, because it complained about a missing ext4 filesystem (obviously that in volume /dev/sda9 which now is encrypted).

That I fixed by deleting the lines for /dev/sda7 and /dev/sda9 in /etc/fstab of 13.1 (in /dev/sda6).

The resulting fstab of 13.1 (in /dev/sda6) is now

/dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X0TDA9-part6 /                    ext3       acl,user_xattr        1 1
/dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X0TDA9-part5 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X0TDA9-part1 /windows/MSsystem    ntfs-3g    ro,user,noauto        0 0
/dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X0TDA9-part8 /home                ext3       defaults              1 2
/dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X0TDA9-part3 /windows/C           ntfs-3g    ro,user,noauto        0 0
/dev/disk/by-id/ata-ST2000NM0033-9ZM175_Z1X0TDA9-part4 /windows/D           ntfs-3g    user                  0 0

part7 (or /dev/sda7, root of 13.2) and part9 (or /dev/sda9, encrypted /home of 13.2) are no longer present here.

13.1 and 13.2 boot fine now.

But when I open a KDE window in 13.1, in the panel on the left hand side of that KDE window, nevertheless under ‘Places / Devices’, the volumes /dev/sda7 and /dev/sda9 are listed by KDE (using different names), although there no longer are entries for them in the corresponding /etc/fstab.

Under usual circumstances I would appreciate this behaviour.
But not in this case:
This desktop is used by several persons, and I don’t need the other users to see that there exists an encrypted volume.

So can I prevent KDE from displaying volumes under ‘Places / Devices’ which are not listed in /etc/fstab ?

Thanks in advance!
Mike

I guess you mean Dolphin, the file manager?

I am afraid it is a misconception of the Dolphin design. That is, in my opinion it is a misconcepetion. The whole idea of the single dirctory tree in Unix/Linux being that the fact that of parts of that directory tree are mounted from different containers (disks, partitions, Logical Volumes, …) is hidden to the end-users.

I am afraid that influence of the Windows way of seeing mass-storage devices as independent, not connected entities is quilty for this design.

Even the concept of user connected mass-storage devices (USB-sticks) does imho not require to show these devices in the infamous Places list of Dolphin. Because there is the popup and there you can tell what you want to do with the device. The fact that the is mounting in the background (and where) should not be of interest to the end-user. (s)he sees e.g. the start of Dolphin (or an eventual other tool like digiKam) pointed to the root directory of the device. No need to know where in the directory tree that is.

But I am sure that many will not be with my old-fashioned approach of the concept of an Operating System hiding the hardware as much away from the user as possible. :wink:

Hi Henk!

Before all: from your reply I see that there may not be an easy solution other than changing the code of KDE/dolphin :wink:

Of course.

In fact, it is hidden to the end-user how this is done. The end-user doesn’t see how this is done, and the end-user thus never learns something about it.

Indeed, openSUSE now is similar to windows in that respect.

If an USB stick/key isn’t displayed in the ‘Places’ list of Dolphin, then you can’t access it using Dolphin. So in this case, I would say, it makes sense to display it in the ‘Places’ list.

My point is that a volume/partition on the internal hard disk should occasionally be treated differently than that on an USB stick/key.

I think I remember that I had a bit trouble to mount external SCSI hard disks under openSUSE 10.
I even had much more trouble then if I physically disconnected such external drives after they had been recognized by the system.
So, in general, I’m quite happy with what Dolphin/KDE does.
But I would like to have a bit more control :wink:

Best wishes, and thanks for the reply!
Mike

So can I prevent KDE from displaying volumes under ‘Places / Devices’ which are not listed in /etc/fstab ?

Thanks in advance!
Mike

Well, you can hide the discovered devices by right-clicking on the respective icons and selecting ‘Hide…’, but of course that won’t stop curious users un-hiding again, with ‘Show All Entries’. Might be enough to keep honest users out though, and of course fstab entries can still be used to set permissions for particular mounts if required.

Great, and it persists even after reboot :wink:

The other users on this desktop are neither hackers, nor experienced, so this really should be sufficient!

And yes, using ‘Show All Entries’ I see the old entries again, even if they appear grey.

Besides, is there a way to undo this?

Anyway, this helped me a lot!
Thank you very much!
Mike

Just found out how to undo the change.

It is so simple.

Always the right mouse click.

I wonder in wich file these changes are strored …

Glad to have been of help. This (XML) configuration is located in ~/.local/share/user-places.xbel

The problem here is in the word “you”. Because it is NOT about the “you” being the OP (in his role as system manager), but many "you"s being the end-users.

IMHO all solutions that require actions from the end-users are worthless in this case. As you say, the user can do this or not and undo this if he wants. Plus all the work to tell all your users (specialy every new user) to do this. Which will probably result in a considarable amount of them doing the opposite of what is asked from them: trying to use those file systems >:).

I interprete the question from the OP as: what can the system manager do (as root) to avoid that the users (the end-users) can see pointers to unmounted (or mounted, why should you have /home mentioned or not in Places dependent of the fact that it is a separate file system?) file systems.

I do not know the answer. As end-user, I hide as much from that Places panel as possible, but that is my personal whim, not forced upon me by my system manager (another role of me).

Well, like you, I hope some usefull information may come forward in this thread :wink:

That is not true IMHO. You access those spontanious connected mass storage devices through the pop-up of the applet and/or the applet itself. That is where the applet is for: showing which mass-storage devices are availble to the session (and thus indirect to the users of the session) and offering the possibilities what to do with it (starting file manager, digiKam, removing safely,…).

That is how to use them IMHO. Not by first starting a file manager, digiKam, etc. and then trying to Open and not knowing where to search.

I hate the words “internal” and “external”. From the system’s (kernel) point of view it is of no importance if a device is inside or outside of the iron case.

Mass-storage devices are either part of the running OS (and then their mounting is configured in /etc/fstab), or they are “spontanious” connected by the session user “in the seat” (USB memory sticks, CDs, DVDs and managed by that user, using the applet). Or, as in your example, they are not to be used at all by the currect running OS. It is the last case that am not sure how to handle as system manager (like you).

The above has nothing to do with “inernal” or “external”. And it is only partly bound to USB or not, because IIRC it is only USB devices that can be connected “on the run”.

Well, I did clarify that end-users could un-hide the entries, but the information displayed there is no different to what can be obtained using ‘fdisk -l’ and ‘mount’ from a user terminal. The real issue is about access, and that can be controlled by fstab entries as I already mentioned and 'polkit can also be used to control access. For example, my Windows partition shows up as ‘/run/media/dean/Windows 7 64 Bit/’ but I can’t mount/browse it at all until I have provided the necessary polkit authentication. Another entry linking to ‘/var/tmp’ is available, but again, I can’t view any of the sub-directories, and the behaviour is identical in my terminal as user

dean@linux-54cw:~> cd /var/tmp
dean@linux-54cw:/var/tmp> dir
total 0
drwx------ 1 dean users 860 Oct 16 12:49 kdecache-dean
drwx------ 1 kdm  kdm    34 Aug 31 10:13 kdecache-kdm
drwx------ 1 root root   76 Oct  4 20:30 kdecache-root
drwx------ 1 root root    6 Sep 12 13:26 systemd-private-2dbeecfcdd0741c8acdb3dc74461af62-rtkit-daemon.service-zXKtOQ
drwx------ 1 root root    6 Sep  8 14:58 systemd-private-7bf466d0948f48cdafbc5c2681da7ea4-rtkit-daemon.service-LvPgOj
drwx------ 1 root root    6 Oct 15 06:50 systemd-private-f2abce9a62484a78908923a21179975d-rtkit-daemon.service-v9NdxA
drwx------ 1 root root   66 Sep 18 08:17 TmpDir.3ZKuyQ
drwx------ 1 root root    0 Sep  8 12:22 TmpDir.D3VbXN
drwx------ 1 root root    0 Sep 18 08:17 TmpDir.kJTEzU
drwx------ 1 root root   66 Sep  8 12:23 TmpDir.kR8tt4
drwx------ 1 root root   66 Aug 27 09:27 TmpDir.pxbeYS
drwx------ 1 root root   66 Aug 31 10:04 TmpDir.w6zPQ7
drwx------ 1 root root   84 Aug 27 09:49 zypp.1IlNaf
drwx------ 1 root root   84 Aug 27 09:39 zypp.35Mrrh
drwx------ 1 root root   84 Aug 31 10:59 zypp.4rRw4w
drwx------ 1 root root   84 Sep 18 08:17 zypp.4tyTwj
drwx------ 1 root root   84 Aug 28 12:05 zypp.6dFQi1
drwx------ 1 root root   84 Aug 27 09:36 zypp.aWZLBX
drwx------ 1 root root   84 Aug 31 09:58 zypp.b7ajpL
drwx------ 1 root root   84 Aug 31 11:02 zypp.C5Nhd0
drwx------ 1 root root   84 Aug 27 09:31 zypp.D0JhIt
drwx------ 1 root root   84 Aug 26 17:43 zypp.DIS80P
drwx------ 1 root root   84 Sep  8 12:23 zypp.Ks4YfZ
drwx------ 1 root root   84 Aug 27 09:27 zypp.nyKY92
drwx------ 1 root root   84 Aug 31 10:14 zypp.oTpswL
drwx------ 1 root root   84 Aug 31 11:14 zypp.S9TU0C
drwx------ 1 root root   84 Aug 31 10:04 zypp.tpKh69
dean@linux-54cw:/var/tmp> cd kdecache-kdm
bash: cd: kdecache-kdm: Permission denied
dean@linux-54cw:/var/tmp> 

So, I don’t see that Dolphin introduces any problem here.

The end-user (specialy the GUI end-user) has “no need to know” anything about mounting, etc. His GUI applications (like Dolphin) should not bother him with ununderstandable and useless information. That some clever end-users may be able to inspect the system further by CLI is something different.
I think we better agree to disagree :wink: to keep this thread free of fruitless discussions.

Well, these kinds of things tend to be a little bit subjective anyway, but I stand by my comments already made in this thread. :slight_smile: