Bug 391706 - 1384f275ab2f1ad1841753ee163af6d1b0bb952b causes problems mounting internal partitions, eSATA-hdds, and LUKS-containers
Summary: 1384f275ab2f1ad1841753ee163af6d1b0bb952b causes problems mounting internal pa...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-solid
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.44.0
Platform: Arch Linux Linux
: NOR grave
Target Milestone: ---
Assignee: Stefan Brüns
URL:
Keywords:
: 391870 397911 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-03-11 10:22 UTC by a92zu
Modified: 2020-12-30 15:44 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.77
Sentry Crash Report:


Attachments
Outputs udisksctl dump solid-hardware5 list details (73.77 KB, text/plain)
2018-04-24 18:43 UTC, a92zu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description a92zu 2018-03-11 10:22:07 UTC
Dear KDE-Team,

I have upgraded from solid 5.43.0-1 to 5.43.0-2 at ArchLinux (solid 5.44.0-1 has also the problem)
I get the following error, when I open/mount my eSATA-hdd and then my LUKS-container with dolphin.

# eSATA-hdd:
An error occurred while accessing 'profile', the system responded: The device is already mounted: Device /dev/sde1 is already mounted at `/run/media/berni/extern'.
=> But it is not mounted

# LUKS container
An error occurred while accessing 'profile', the system responded: The device is already mounted: Device /dev/dm-1 is already mounted at `/run/media/berni/decrypted-extern'.
=> But it is not mounted

Then I press the device's button on dolphin again and the refresh button (F5), then the esata-hdd/LUKS-container is mounted.


Downgrading to solid 5.43.0-1 helps.

The following commit seems to be the culprit.

KDE Bug: https://bugs.kde.org/show_bug.cgi?id=389479

Fix device auto-mounting
git-svn-id: file:///srv/repos/svn-packages/svn@317478 eb2447ed-0c53-47e4-bac8-5bc4a241df78

Faulty commit is:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/solid&id=069d565428658007ba8f983a06c8cd776d702d18

faulty version: solid 5.43.0-2

last working: solid 5.43.0-1 with linux-lts and linux kernel

Please look into the problem.


Best regards, berni
Comment 1 Patrick Silva 2018-03-11 13:29:16 UTC
After update to frameworks 5.44 sometimes I also get "partition already mounted" bug when I try to mount ntfs partiton in dolphin. I have 3 nfts partitions, first of them is mounted correctly after I enter my password, but dolphin fails to mount my other two partitions.
This probem occurs when automount is disabled in "removable devices" kcm.
I also use Arch Linux.
Comment 2 Nate Graham 2018-03-11 20:33:26 UTC
Kai, this was apparently caused by the patch to fix the issue caused by https://cgit.kde.org/solid.git/commit/?id=1384f275ab2f1ad1841753ee163af6d1b0bb952b. Since you're somewhat familiar with this code, would you mind taking a look? Also it would be really nice to get some more tests on this code, since apparently it's pretty fragile.
Comment 3 Kai Uwe Broulik 2018-03-12 10:08:54 UTC
Did https://cgit.kde.org/solid.git/commit/?id=e94ba0619477e990903abd0ea0ab584b98dbac08 have any effect on this?
Comment 4 Nate Graham 2018-03-12 16:48:13 UTC
Apparently that fixed auto-mount issues for removable disks, but not internal ones? Not totally clear.
Comment 5 Patrick Silva 2018-03-15 02:08:11 UTC
*** Bug 391870 has been marked as a duplicate of this bug. ***
Comment 6 Unknown 2018-03-15 15:36:55 UTC
I can confirm that internal SATA disks aren't automounting when selected in kcm_deviceautomounter module of System Settings, and I'm also getting the error Dr. Chapatin mentioned when trying to mount an ntfs partition in Dolphin: "The device is already mounted".

Running Antergos (Arch), KDE Frameworks 5.44.0, Plasma 5.12.3.
Comment 7 Nate Graham 2018-03-19 21:54:14 UTC
> Did https://cgit.kde.org/solid.git/commit/?id=e94ba0619477e990903abd0ea0ab584b98dbac08 have any effect on this?

It seems to have resolved Bug 389479, but then caused this one.
Comment 8 Stefan Brüns 2018-03-20 00:41:03 UTC
I think the culprit is the following line in the automounter:

https://github.com/KDE/plasma-desktop/blob/master/solid-device-automounter/kded/DeviceAutomounter.cpp#L70

    Solid::StorageAccess *sa = dev.as<Solid::StorageAccess>();
    if (sa->isIgnored()) {
        return;
    }
    ..

    if (AutomounterSettings::shouldAutomountDevice(dev.udi(), type)) {
        Solid::StorageVolume *sv = dev.as<Solid::StorageVolume>();
        if (!sv->isIgnored()) {
            sa->setup();
        }
    }

The original code [1] only checked for sv->isIgnored(), see https://github.com/KDE/kde-runtime/blame/d34c3c6cf91de9d1abd3eab73ffd0a3baf8f00e1/solid-device-automounter/kded/DeviceAutomounter.cpp

The sa->isIgnored() was added when "porting" the code to KF5.

As far as I can see the sa->isIgnored() check should be removed, and the path.empty() check in solid should be reverted.
Comment 9 a92zu 2018-04-02 16:53:16 UTC
Downgrading to udisks2-2.7.5-1 (from version 2.7.6-1) helps too.
Comment 10 Nate Graham 2018-04-03 21:20:02 UTC
Thanks Stefan! Would you like to submit a patch?
Comment 11 Paul 2018-04-07 11:30:55 UTC
See also:

https://github.com/storaged-project/udisks/issues/502
Comment 12 Stefan Brüns 2018-04-08 19:44:31 UTC
Can anyone affected provide the output of
$> udisksctl dump
Comment 13 Stefan Brüns 2018-04-09 01:33:48 UTC
Git commit 122a6cd8989a4bd3096fddea908a1c2b223be62a by Stefan Brüns.
Committed on 09/04/2018 at 01:33.
Pushed by bruns into branch 'master'.

[UDisks] Correct handling of removable file systems

Summary:
Filesystems which have no fstab entry have an empty filepath (aka
mountpoint), but these should be mountable nevertheless.
The StorageAccess.ignored flag should only be used as a hint if a
device (filesystem) should create a device item in e.g Dolphin.
Related: bug 389479

Reviewers: ngraham, broulik

Reviewed By: ngraham

Subscribers: #frameworks

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D12051

M  +4    -4    src/solid/devices/backends/udisks2/udisksstorageaccess.cpp

https://commits.kde.org/solid/122a6cd8989a4bd3096fddea908a1c2b223be62a
Comment 14 Caqui 2018-04-23 13:06:23 UTC
Thanks for all your effort, but I'm sorry to say that this is still not fixed in solid 5.45.0. I can still reproduce it with that version of solid and dolphin 18.04.0.

(In reply to Stefan Brüns from comment #12)
> Can anyone affected provide the output of
> $> udisksctl dump

https://pastebin.com/raw/khgBhsAN
Comment 15 Nate Graham 2018-04-23 13:10:35 UTC
Darn, thanks for commenting and adding the requested log information. Hopefully Stefan can take a look.
Comment 16 a92zu 2018-04-23 15:11:07 UTC
I can confirm that too. 
There is still the problem with USB,eSATA and LUKS-devices.

Downgrading to udisks 2.7.5 helps, or recompiling udisks 2.7.6 without libmount-support.
Comment 17 Stefan Brüns 2018-04-23 15:13:25 UTC
(In reply to berni from comment #16)
> I can confirm that too. 
> There is still the problem with USB,eSATA and LUKS-devices.
> 
> Downgrading to udisks 2.7.5 helps, or recompiling udisks 2.7.6 without
> libmount-support.

As you have already set this up, can you please provide the output of:
$> udiscsctl dump
$> solid-hardware5 list details

for *both* cases, i.e. with and without libmount?
Comment 18 Stefan Brüns 2018-04-24 16:51:24 UTC
udiskctl, solid-hardware5 output
Comment 19 a92zu 2018-04-24 18:43:11 UTC
Created attachment 112219 [details]
Outputs  udisksctl dump solid-hardware5 list details

Outputs  
udisksctl dump 
solid-hardware5 list details
Comment 20 Christoph Feck 2018-05-16 18:10:32 UTC
Thanks for the update; changing status for inspection.
Comment 21 Caqui 2018-05-17 08:52:25 UTC
This bug is not happening anymore for me. Seems it was fixed somehow. :)
Comment 22 Nate Graham 2018-05-17 21:17:29 UTC
Can any other users of bleeding-edge distros confirm the status of this bug with KDE Frameworks 5.46? Fixed/not fixed?
Comment 23 a92zu 2018-05-18 10:34:30 UTC
Yes, it is working with KDE Frameworks 5.46 too and was fixed in ArchLinux with commit:

# kdebug-370975
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/solid&id=d096a1e780bbe5a75d83910b0eb54140a7299642

There are other issues with umounting and mounting again partitions in dolphin, eSata-hdds, but for these I will open another bug report.

I have set the status to "resolved , fixed"

Thank you for your support!
Best regards, Bernhard
Comment 24 Nate Graham 2018-05-18 13:09:10 UTC
Yay!

Perhaps your remaining issues are tracked by Bug 389479?
Comment 25 Nate Graham 2018-08-27 19:45:10 UTC
*** Bug 397911 has been marked as a duplicate of this bug. ***
Comment 26 Caqui 2018-10-10 09:02:56 UTC
This is back for LUKS containers (or maybe it was never completely gone, I did never tested LUKS containers, I didn't even knew what they were last time I posted here).

I have recorded a video, just in case it helps. It will be in this link for a month: https://my.owndrive.com/index.php/s/fshtH0Oi70eKQhG

Thanks!
Comment 27 Stefan Brüns 2018-10-10 09:59:37 UTC
(In reply to José Alberto from comment #26)
> This is back for LUKS containers (or maybe it was never completely gone, I
> did never tested LUKS containers, I didn't even knew what they were last
> time I posted here).
> 
> I have recorded a video, just in case it helps. It will be in this link for
> a month: https://my.owndrive.com/index.php/s/fshtH0Oi70eKQhG
> 
> Thanks!

Please describe exactly
- how your setup looks like
- what you do
- what happens

I will *not* try to extract information from some random internet video link!
Comment 28 Caqui 2018-10-10 10:27:29 UTC
(In reply to Stefan Brüns from comment #27)
> (In reply to José Alberto from comment #26)
> > This is back for LUKS containers (or maybe it was never completely gone, I
> > did never tested LUKS containers, I didn't even knew what they were last
> > time I posted here).
> > 
> > I have recorded a video, just in case it helps. It will be in this link for
> > a month: https://my.owndrive.com/index.php/s/fshtH0Oi70eKQhG
> > 
> > Thanks!
> 
> Please describe exactly
> - how your setup looks like
> - what you do
> - what happens
> 
> I will *not* try to extract information from some random internet video link!

I didn't open a new bug because the setup has always been the same, you can find all the things you ask for in the first comment talking about luks containers. If you need more info than that, just ask more specifically and I'll give more information (see https://bugs.kde.org/show_bug.cgi?id=391706#c14 ).

The video was *not* even necessary, I just added it in case it helps, it's not a random internet video, I recorded it. I cared to do it very straightforward so you can see what is happening (starts without pendrive, plug the pendrive, click on luks partition in dolphin, get the bug, repeat the bug by unmounting and mounting again).


> I will *not* try to extract information from some random internet video link!

Don't worry, I will not do it ever again, it seems I wasted my time on it. I did what I could, I don't have enough knowledge to try to fix it (if I had it, I would have tried it instead of recording a video, yes).
Comment 29 Stefan Brüns 2018-10-10 23:38:03 UTC
(In reply to José Alberto from comment #28)
> (In reply to Stefan Brüns from comment #27)
> > (In reply to José Alberto from comment #26)
> > > This is back for LUKS containers (or maybe it was never completely gone, I
> > > did never tested LUKS containers, I didn't even knew what they were last
> > > time I posted here).
> > > 
> > > I have recorded a video, just in case it helps. It will be in this link for
> > > a month: https://my.owndrive.com/index.php/s/fshtH0Oi70eKQhG
> > > 
> > > Thanks!
> > 
> > Please describe exactly
> > - how your setup looks like
> > - what you do
> > - what happens
> > 
> > I will *not* try to extract information from some random internet video link!
> 
> I didn't open a new bug because the setup has always been the same, you can
> find all the things you ask for in the first comment talking about luks
> containers. If you need more info than that, just ask more specifically and
> I'll give more information (see
> https://bugs.kde.org/show_bug.cgi?id=391706#c14 ).

I asked *you* about *your* setup. It may be similar or even identical to the one originally reported, but without detailed information it is impossible to know.

It is also impossible to know if your setup is completely unaltered since, this includes any other software, e.g. kernel, udev, udisks2 at least.

It is not possible to check the data you provided earlier (which may be deprecated anyway) as the pastebin has vanished.
Comment 30 Caqui 2018-10-11 08:42:55 UTC
(In reply to Stefan Brüns from comment #29)
> I asked *you* about *your* setup. It may be similar or even identical to the
> one originally reported, but without detailed information it is impossible
> to know.
> 
> It is also impossible to know if your setup is completely unaltered since,
> this includes any other software, e.g. kernel, udev, udisks2 at least.

OK, sorry, I thought it was not useful given the old information, as it has even been pointed out which commit introduced this and what solved it partially.

My setup:

Archlinux
linux 4.18.12..arch1-1 (also with 4.18.9.arch1-1)
libsystemd 239.2-1
systemd 239.2-1
udisks2 2.8.1-1 (also 2.8.0-1)
solid 5.50.0-1
kde-applications 18.08.1

If you need something else, just ask, I don't know if I'm missing something important or not.

> - what you do
> - what happens

I plug in a pendrive (gpt partition table, luks2 encrypted ext4 partition).
It appears in dolphin,
I click on "3.7 GiB Encrypted Drive" to open it.
It raises an error saying

    An error occurred while accessing '3.7 GiB Hard Drive', the system responded:
    The device is already mounted: Device /dev/dm-0 is already mounted at
    `/run/media/ja/08ef0bd7-52fe-468e-95fe-55a3b19fe074'.

It's true, it's mounted there, but it should have also being opened.
If I click again on "3.7 GiB Encrypted Drive", it's opened.

> It is not possible to check the data you provided earlier (which may be
> deprecated anyway) as the pastebin has vanished.

I know, it was just to show you that I've been always willing to help. I'm not demanding for a fix (nor with any other bug, ever), nor I wanted you to extract information from a random internet video.
Comment 31 Stefan Brüns 2018-10-11 22:14:34 UTC
This looks like a good starting point, thanks.

Will probably look into it during the weekend.
Comment 32 Caqui 2018-10-16 14:55:45 UTC
Thank you. =)

Can we mark this as reopened so it doesn't get lost?
Comment 33 Lua 2020-09-17 17:13:57 UTC
I'm still having this bug in Kubuntu 20.04 with Dolphin 19.12.3.
Comment 34 Jürgen Thomann 2020-12-28 11:24:00 UTC
I had this problem with LUKS encrypted external disks as well and it seems to be solved for me with libKF5Solid5-5.77.0 on openSUSE Tumbleweed
Comment 35 Nate Graham 2020-12-30 15:44:55 UTC
Yay, thanks for confirming! It's been working for me too with my LUKS HDD too, FWIW.