Bug 391706

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.

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.

Did https://cgit.kde.org/solid.git/commit/?id=e94ba0619477e990903abd0ea0ab584b98dbac08 have any effect on this?

Apparently that fixed auto-mount issues for removable disks, but not internal ones? Not totally clear.

*** Bug 391870 has been marked as a duplicate of this bug. ***

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.

> 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.

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.

Downgrading to udisks2-2.7.5-1 (from version 2.7.6-1) helps too.

Thanks Stefan! Would you like to submit a patch?

See also:

https://github.com/storaged-project/udisks/issues/502

Can anyone affected provide the output of
$> udisksctl dump

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

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

Darn, thanks for commenting and adding the requested log information. Hopefully Stefan can take a look.

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.

(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?

udiskctl, solid-hardware5 output

Created attachment 112219 [details]
Outputs  udisksctl dump solid-hardware5 list details

Outputs  
udisksctl dump 
solid-hardware5 list details

Thanks for the update; changing status for inspection.

This bug is not happening anymore for me. Seems it was fixed somehow. :)

Can any other users of bleeding-edge distros confirm the status of this bug with KDE Frameworks 5.46? Fixed/not fixed?

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

Yay!

Perhaps your remaining issues are tracked by Bug 389479?

*** Bug 397911 has been marked as a duplicate of this bug. ***

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!

(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!

(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).

(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.

(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.

This looks like a good starting point, thanks.

Will probably look into it during the weekend.

Thank you. =)

Can we mark this as reopened so it doesn't get lost?

I'm still having this bug in Kubuntu 20.04 with Dolphin 19.12.3.

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

Yay, thanks for confirming! It's been working for me too with my LUKS HDD too, FWIW.