Hello. I have installed KDE NEON with KDE PLASMA 5.11.5. Later of updates of 26 January of 2018 when i insert a disk, plasma not show notification and not automount. Neither show devices connect in dolphin. I can mount the devices in console and then dolphin show devices. I have that mount devices manually in console for access.
Same bug here, and other reddit users are experiencing it as well: https://www.reddit.com/r/kde/comments/7t6g33/device_notifier_not_showing_usb_drives/ I have my drives to automatically mount when attached, and they are; they just don't show up in dolphin or the notifier widget.
Same issue trying to see the contents of a USB stick I get no notification in Status & Notification it also does not display in Dolphin, however, it displays that it is connecting in System Settings Removable Devices. This issue came up after the last update January 26th, 2018 KDE Neon User Edition with plasma 5.11.5
Could be a duplicate of bug 389358.
I noticed that since yesterday my NTFS partition is not mounted on boot on neon dev unstable.
I have updated today my system and now Plasma show notification when i connect a disk but this not automount. I have to go to dolphin and do click on devices for this will be mount. I have selected for that mount devices automatic when this will be connect in systemsettings but this not run.
Please provide your version of KDE frameworks.
(In reply to David Edmundson from comment #6) > Please provide your version of KDE frameworks. 5.42.0
(In reply to David Edmundson from comment #6) > Please provide your version of KDE frameworks. I have KDE FRAMEWORK 5.42.0
Frameworks 5.42.0 as well. After an update to solid some days ago, things are working again.
Created attachment 110270 [details] Config Removable Devices
Created attachment 110271 [details] Disk USB not automount Disk USB or second disk of PC not aumount when i connect or boot PC
Same here: disks aren't automatically even though I've set them to do so in the Removable Devices kcm.
This is not fixed completely. Now Plasma show notification when i connect a disk but this not automount. I have to go to dolphin and do click on devices for this will be mount. I have selected for that mount devices automatic when this will be connect in systemsettings but this not run.
My neon dev unstable is still not mounting the NTFS partition of my internal hard disk on boot despite automount is enabled in kcm.
plasma 5.12 also did not mount my NTFS partitions on boot. I had to use gnome-disks to set my partitions to mount on boot because settings in "removable devices" kcm do no effect.
*** Bug 390173 has been marked as a duplicate of this bug. ***
I confirm this bug, on KDE Neon LTS edition plasma 5.12.
This bug also exists on: KDE Plasma Version: 5.12.1 KDE Frameworks Version: 5.43.0 Qt Version: 5.9.3 Kernel Version: 4.13.0-32-generic In case this help, when launching KDE Partition Manager with an external USB HDD attached, the following prompt appears: "No support tools were found for file systems currently present on hard disks in this computer: Partition File System Support Tools URL /dev/sdc3 hfsplus diskdev_cmds http://opendarwin.org As long as the support tools for these file systems are not installed you will not be able to modify them. You should find packages with these support tools in your distribution's package manager."
*** Bug 390555 has been marked as a duplicate of this bug. ***
I have the same bug on Manjaro. Automount of NTFS partitions dosen't work. KDE Plasma 5.12.1 KDE Framework 5.43.0 Qt 5.10.0 Kernel 4.14.19-1-MANJARO OS 64-bit
I confirm. Just updated Manjaro to Plasma 5.12.1, KDE Framework 5.43.0 with kernel 4.15.3-2, Qt 5.10.0 and automounting is gone. After pluging in my external hard drive I see notification about the device on my panel and I can mount it from there but it's not automounted like before which is very annoying. Other Manjaro Plasma users report the same problem here: https://forum.manjaro.org/t/stable-update-2018-02-17-kernels-kde-mate-firefox-libreoffice-mesa-systemd/40582/4 It's very important to me that external devices are automounted so I consider this a serious drawback.
Add me to the list: KDE Plasma 5.12.1 KDE Framework 5.43.0 Qt 5.10.0 Kernel 4.14.19-1-MANJARO OS 64-bit Also it seems that the system settings in the control centre for removable media (Wechseldatenträger) have no effect; whatever I change, no automount of nothing. systemd 237-31.1 udisks2 2.5.7-1
(In reply to Dr. Chapatin from comment #16) > *** Bug 390173 has been marked as a duplicate of this bug. *** In possibility of my report being ignored since duplication, I want to notice devs about that downgrading KDE Frameworks to 5.42 fixes this problem. I think the root cause is in between KF5 and Plasma and about how they communicate. I've provided some logs in my report and can give more info if needed.
Kai, could this be related to changes in solid framework?
Have the same problem. "Automount on login" broken with plasma 5.12 and Frameworks 5.43 downgrading solid to 5.42 alone solves the issue
Can you please check the output of solid-hardware5 list and then do solid-hardware5 details /path/to/the/offending/device (it could show up multiple times, e.g. as block device and as usb stick). Can you try whether reverting ed1e7f5fc5c083c17bd44e4220a35eae140f980b and 1384f275ab2f1ad1841753ee163af6d1b0bb952b in Solid helps?
Created attachment 110815 [details] output of solid-hardware5 #27
(In reply to Kai Uwe Broulik from comment #26) > Can you please check the output of solid-hardware5 details /path/to/the/offending/device (it could show up > multiple times, e.g. as block device and as usb stick). see the attachment > Can you try whether reverting ed1e7f5fc5c083c17bd44e4220a35eae140f980b and > 1384f275ab2f1ad1841753ee163af6d1b0bb952b in Solid helps? Yes, this helps.
Same Here Frameworks 5.43. Opensuse Tumbleweed Thanks
Created attachment 110820 [details] don't ignore storage with empty path Actually, I've added debug output to StorageAccess::isIgnored (udisks2/udisksstorageaccess.cpp): StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sdd1' path:'' (empty,ignored) StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sdb2' path:'' (empty,ignored) StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sdc1' path:'' (empty,ignored) StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sda7' path:'' (empty,ignored) StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sda6' path:'/home' (non-empty,ignored) StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sda5' path:'/' (non-empty,ignored) StorageAccess::isIgnored udi:'/org/freedesktop/UDisks2/block_devices/sda3' path:'/boot' (non-empty,ignored) All devices that was auto-mountable before 5.43 has empty path. I've added isEmpty check and it works like a charm now. Please check the patch
Thanks for the patch! Patches in bug reports tend to get missed, so please submit this using Phabricator. For documentation regarding how to do this, see https://community.kde.org/Infrastructure/Phabricator
(In reply to Nate Graham from comment #31) > Thanks for the patch! Patches in bug reports tend to get missed, so please > submit this using Phabricator. For documentation regarding how to do this, > see https://community.kde.org/Infrastructure/Phabricator I've tried my best but I have no idea who should be reviewer https://phabricator.kde.org/D10671
Thanks for your patch! You did a great job following the right formatting, too. I added some appropriate reviewers.
Git commit e94ba0619477e990903abd0ea0ab584b98dbac08 by Nathaniel Graham, on behalf of Dmitry Khlestkov. Committed on 24/02/2018 at 14:16. Pushed by ngraham into branch 'master'. [UDisks] Fix auto-mount regression Summary: Devices with empty path stopped auto-mounting after commit 1384f275ab2f1ad1841753ee163af6d1b0bb952b. This diff fixes the regression by checking if the path is empty. Reviewers: #frameworks, broulik Reviewed By: broulik Subscribers: ngraham, sefaeyeoglu, rikmills, #frameworks Tags: #frameworks Differential Revision: https://phabricator.kde.org/D10671 M +2 -1 src/solid/devices/backends/udisks2/udisksstorageaccess.cpp https://commits.kde.org/solid/e94ba0619477e990903abd0ea0ab584b98dbac08
Already fixed on Arch \o/ https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/solid&id=069d565428658007ba8f983a06c8cd776d702d18
When updates fix for KDE Neon?
*** Bug 391192 has been marked as a duplicate of this bug. ***
*** Bug 391195 has been marked as a duplicate of this bug. ***
*** Bug 391235 has been marked as a duplicate of this bug. ***
I see the fix is mentioned in Framework 5.44. (link: https://www.kde.org/announcements/kde-frameworks-5.44.0.php )
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. Fix device auto-mounting git-svn-id: file:///srv/repos/svn-packages/svn@317478 eb2447ed-0c53-47e4-bac8-5bc4a241df78 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
Faulty commit is: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/solid&id=069d565428658007ba8f983a06c8cd776d702d18
I have opened a new bug report for my problem https://bugs.kde.org/show_bug.cgi?id=391706
This bug is not fixed on Arch Linux running frameworks 5.44. Only removable devices (pendrive, for example) are mounted on boot. I have 3 ntfs partitions, none of them is mounted on boot.
Let's track the remaining issues in Bug 391706.
Re-opening since this specific issue is apparently not fixed (sorry everyone). Luckily, there's a patch: https://phabricator.kde.org/D12050
Git commit 8dedbcdf4197eccd5e06c18a66a63d15615c8171 by Stefan Brüns. Committed on 09/04/2018 at 01:07. Pushed by bruns into branch 'master'. Make automounting work even if StorageAccess is ignored Summary: There is no reason to make mounting dependent on the StorageAccess.ignore flag, which just serves a a hint for visualization. This change sneaked in when porting to KF5, no justification given. Reviewers: ngraham, #plasma, broulik Reviewed By: ngraham Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D12050 M +0 -3 solid-device-automounter/kded/DeviceAutomounter.cpp https://commits.kde.org/plasma-desktop/8dedbcdf4197eccd5e06c18a66a63d15615c8171
Git commit 2da93ae0a3099021646e4a743fca3ca47ee36376 by Stefan Brüns. Committed on 09/04/2018 at 01:16. Pushed by bruns into branch 'Plasma/5.12'. Make automounting work even if StorageAccess is ignored Summary: There is no reason to make mounting dependent on the StorageAccess.ignore flag, which just serves a a hint for visualization. This change sneaked in when porting to KF5, no justification given. Reviewers: ngraham, #plasma, broulik Reviewed By: ngraham Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D12050 M +0 -3 solid-device-automounter/kded/DeviceAutomounter.cpp https://commits.kde.org/plasma-desktop/2da93ae0a3099021646e4a743fca3ca47ee36376
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 391706 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
Patch was already applied on Arch Linux, patched packages are installed on my system but the problem persists. I use 3 hard disks: sda has two partitions (ext4 and ntfs) sdb has one ntfs partition sdc has one ntfs partition When automount is enabled in "removable devices" kcm, none of my ntfs partitions is mounted on boot and plasma immediately asks for password to mount ntfs partition from sda when plasma session is started. So I cancel the password dialog, open dolphin, click the entry of some ntfs partition in dolphin sidebar, dolphin asks for password, I enter my password and the partition is mounted. I click the entry of second ntfs partition, dolphin mounts it without to ask for password. However dolphin shows "The device is already mounted" error when I try to mount third ntfs partition by clicking its entry in the sidebar. If I to type my password in dialog shown when plasma session is started, ntfs partition from sda is mounted. Dolphin mounts the second partition without to ask for password and I get "The device is already mounted" error when I try to mount third partition.
(In reply to Dr. Chapatin from comment #50) > Patch was already applied on Arch Linux, patched packages are installed on > my system but the problem persists. This patch from yesterday? https://commits.kde.org/solid/122a6cd8989a4bd3096fddea908a1c2b223be62a If so, has Arch already patched in the second part of the fix? https://cgit.kde.org/solid.git/commit/?id=122a6cd8989a4bd3096fddea908a1c2b223be62a
122a6cd8989a4bd3096fddea908a1c2b223be62a was applied to solid package https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/solid&id=3cb14742f9f424692df6f2148017db8eff627a41 2da93ae0a3099021646e4a743fca3ca47ee36376 was applied to plasma-desktop package https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/plasma-desktop&id=28a398d9f4d98be2cde5b40a38b1cfdd64a46756
(In reply to Dr. Chapatin from comment #52) > 122a6cd8989a4bd3096fddea908a1c2b223be62a was applied to solid package > > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ > solid&id=3cb14742f9f424692df6f2148017db8eff627a41 > > 2da93ae0a3099021646e4a743fca3ca47ee36376 was applied to plasma-desktop > package > > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ > plasma-desktop&id=28a398d9f4d98be2cde5b40a38b1cfdd64a46756 Please provide the output of $> solid-hardware list details and $> udisksctl dump
Created attachment 111924 [details] udisksctl dump "solid-hardware list details" command not found here.
solid-hardware5 it is for KF5
Created attachment 111925 [details] solid-hardware5
(In reply to Dr. Chapatin from comment #56) > Created attachment 111925 [details] > solid-hardware5 Apparently solid get seriously confused: udi = '/org/freedesktop/UDisks2/drives/ST31000524AS_5VP818CG' parent = '/org/freedesktop/UDisks2' (string) vendor = '' (string) product = 'ST31000524AS' (string) description = 'Disco rígido 931,5 GiB' (string) Block.major = 0 (0x0) (int) Block.minor = 2081 (0x821) (int) Block.device = '/dev/sdc1' (string) StorageDrive.bus = 'Sata' (0x4) (enum) StorageDrive.driveType = 'HardDisk' (0x0) (enum) StorageDrive.removable = false (bool) StorageDrive.hotpluggable = false (bool) StorageDrive.inUse = true (bool) StorageDrive.size = 1000203804160 (0xe8e0cade00) (qulonglong) ^ Thats a mix of /dev/sdc (StorageDrive.*) and /dev/sdc1 (Block.*). Same applies for sda3 and sdb1. Maybe this causes the errors with mounting. I can see something equivalent with my openSUSE TW, udisks 2.7.6 (using libmount), KF5.44. Can someone provide the solid-hardware5 output for a StorageDrive.driveType = 'HardDisk' on a system with udisks 2.7.5, i.e. without libmount?
Maybe https://cgit.kde.org/solid.git/commit/?id=d735708ff11c40ee6b9bee64544250d55067403f would help with the remaining errors?
Auto-mounting is still not working correctly on my system. Partitions of internal hard disks are not mounted on boot when auto-mounting feature is enabled in "removable devices" kcm. Arch Linux plasma 5.12.5 frameworks 5.46 udisks2 2.7.6-1
(In reply to Dr. Chapatin from comment #59) > Auto-mounting is still not working correctly on my system. > Partitions of internal hard disks are not mounted on boot > when auto-mounting feature is enabled in "removable devices" kcm. Situation remains the same on Arch Linux after upgrade to plasma 5.13 and frameworks 5.47.
As I don't have this issue in any of my installations (including Arch, KDE neon User and -Unstable) I will just silently leave the room (remove me from CC)
There was a bug in old Plasma version but it was fixed long time ago. I also can't confirm this bug. Mounting works fine on Manjaro Plasma 5.13.0 and KDE Framework 5.47 as it was in previous version.
We have conflicting information. Dr Chapatin says he can reproduce on 5.47. Sefa and Michał say they cannot. Are all of you testing whether mountable partitions on your internal disks are auto-mounted on boot when auto-mount is turned on in System Settings > Removable Storage > Removable Devices? Are any of you using the "Device Overrides" table to force automounting for your partitions?
The problem does not occur on my laptop running kde neon unstable. My laptop has just one hard disk with 1 ntfs partition and 2 ext4 partitions. NTFS partition is mounted on boot as expected. The problem occurs on my desktop running Arch Linux, this computer has 3 hard disks: hd A has 1 ext4 partition and 1 ntfs partition; both hd B and hd C have 1 ntfs partition; None of the NTFS partitions is mounted on boot. I created a new user account for test purposes and got the same result. Removable devices are mounted as expected. Stefan identified some problem on my system - comment 57
Hmm, I wonder if the issue with your NTFS-only disks might actually be Bug 392913 instead. Do they appear if you turn on "Show Hidden Files"?
I think it's not related to bug 392913. The same partitions are mounted on boot when I use Gnome Disks. https://asksolus.com/question/how-to-auto-mount-drives-on-statup-in-solus/
My all SSD and HDD partitions are correctly mounted on boot. When pluging in external hard drives and USB's, they are also correctly auto-mounted and I get proper indication in systray. In System Settings > Removable Storage > Removable Devices I have only checked one of the HDD partitions and my external hard drive but my fstab had entries to mount all available computer partitions. Again, as to any other external mounts, they get auto-mounted just fine. I recall having auto-mount issue and many users on Manjaro forum mentioned it as well after certain update. Then fix arrived (after a week or so) and problem went away immediately and people stop mentioning it on Manjaro forums.That plus fact that others also can't reproduce the issue points that Dr. Chapatin's problem is an individual one and not a general Plasma bug. What is the journalctl or dmsg output when plugging in the external drives/usb's on your system Dr. Chapatin? Maybe there is an error pointing out where to look at? Or actually I would browse through errors to find if something is not related to the problem. For current boot: - errors journalctl -b -p3 - warnings and erros journalctl -b -p4
journalctl -b -p3 -- Logs begin at Tue 2018-02-27 15:13:40 -03, end at Tue 2018-06-19 12:0> jun 19 12:03:44 Arch-PC nmbd[375]: [2018/06/19 12:03:43.997482, 0] ../s> jun 19 12:03:44 Arch-PC nmbd[375]: started asyncdns process 380 jun 19 12:03:44 Arch-PC nmbd[375]: [2018/06/19 12:03:44.418906, 0] ../l> jun 19 12:03:44 Arch-PC nmbd[375]: daemon_ready: STATUS=daemon 'nmbd' > jun 19 12:03:45 Arch-PC smbd[382]: [2018/06/19 12:03:45.940600, 0] ../l> jun 19 12:03:45 Arch-PC smbd[382]: daemon_ready: STATUS=daemon 'smbd' > jun 19 12:04:59 Arch-PC systemd-coredump[811]: Process 750 (baloo_file_e> Stack trace of thread 750: #0 0x00007f409f9e986b ra> #1 0x00007f409f9d440e ab> #2 0x00007f409f351ce2 n/> #3 0x00007f409f346c75 n/> #4 0x00007f409f347e9b n/> #5 0x00007f409f348129 n/> #6 0x00007f409f349d54 n/> #7 0x00007f409f34dfda md> #8 0x00007f409f34f64c n/> #9 0x00007f40a21762ef _Z> #10 0x00007f40a219af84 _Z> #11 0x00005626e1669603 n/> #12 0x00007f40a039fcc7 n/> #13 0x00007f40a039438b _Z> #14 0x00007f40a10dda74 _Z> #15 0x00007f40a10e5341 _Z> #16 0x00007f40a0369cb9 _Z> #17 0x00007f40a03bc40a _Z> #18 0x00007f40a03bcc92 n/> #19 0x00007f409cb60368 g_> #20 0x00007f409cb605b1 n/> #21 0x00007f409cb6063e g_> #22 0x00007f40a03bd039 _Z> #23 0x00007f4098562722 n/> #24 0x00007f40a036894c _Z> #25 0x00007f40a0370c46 _Z> #26 0x00005626e1666d70 n/> #27 0x00007f409f9d606b __> #28 0x00005626e1666eaa _s> Stack trace of thread 773: #0 0x00007f409faa0ea9 __> #1 0x00007f409924c180 n/> #2 0x00007f409924de4b xc> #3 0x00007f40984cd22a n/> #4 0x00007f40a01bbb45 n/> #5 0x00007f409f12b075 st> #6 0x00007f409faab53f __> Stack trace of thread 809: #0 0x00007f409faa0ea9 __> #1 0x00007f409cb60523 n/> #2 0x00007f409cb6063e g_> #3 0x00007f40a03bd039 _Z> #4 0x00007f40a036894c _Z> #5 0x00007f40a01b1a99 _Z> #6 0x00007f40a1ce1976 n/> #7 0x00007f40a01bbb45 n/> #8 0x00007f409f12b075 st> #9 0x00007f409faab53f __> lines 45-60/60 (END)
journalctl -b -p4 -- Logs begin at Tue 2018-02-27 15:13:40 -03, end at Tue 2018-06-19 12:0> jun 19 12:03:33 Arch-PC kernel: r8169 0000:04:00.0: can't disable ASPM; > jun 19 12:03:44 Arch-PC nmbd[375]: [2018/06/19 12:03:43.997482, 0] ../s> jun 19 12:03:44 Arch-PC nmbd[375]: started asyncdns process 380 jun 19 12:03:44 Arch-PC nmbd[375]: [2018/06/19 12:03:44.418906, 0] ../l> jun 19 12:03:44 Arch-PC nmbd[375]: daemon_ready: STATUS=daemon 'nmbd' > jun 19 12:03:45 Arch-PC smbd[382]: [2018/06/19 12:03:45.940600, 0] ../l> jun 19 12:03:45 Arch-PC smbd[382]: daemon_ready: STATUS=daemon 'smbd' > jun 19 12:03:50 Arch-PC sddm-greeter[400]: QObject: Cannot create childr> (Parent is SDDM::GreeterApp(0> jun 19 12:03:50 Arch-PC sddm-greeter[400]: QObject: Cannot create childr> (Parent is SDDM::GreeterApp(0> jun 19 12:03:50 Arch-PC sddm-greeter[400]: QObject: Cannot create childr> (Parent is SDDM::GreeterApp(0> jun 19 12:03:50 Arch-PC sddm-greeter[400]: QObject: Cannot create childr> (Parent is SDDM::GreeterApp(0> jun 19 12:03:50 Arch-PC sddm-greeter[400]: QObject::installEventFilter()> jun 19 12:03:50 Arch-PC sddm-greeter[400]: QObject: Cannot create childr> (Parent is SDDM::GreeterApp(0> jun 19 12:03:53 Arch-PC sddm-greeter[400]: QObject: Cannot create childr> (Parent is SDDM::GreeterApp(0> jun 19 12:03:53 Arch-PC sddm-greeter[400]: QObject::installEventFilter()> jun 19 12:03:54 Arch-PC sddm-greeter[400]: Cannot watch QRC-like path ":> jun 19 12:03:56 Arch-PC sddm-greeter[400]: file:///usr/share/sddm/themes> jun 19 12:03:57 Arch-PC sddm-greeter[400]: QDBusConnection: name 'org.fr> jun 19 12:04:05 Arch-PC klauncher[479]: Connecting to deprecated signal > jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:07 Arch-PC kdeinit5[482]: kf5.kded: No X-KDE-DBus-ServiceNa> jun 19 12:04:13 Arch-PC ksmserver[523]: Qt: Session management error: ne> jun 19 12:04:14 Arch-PC kdeinit5[482]: kscreen.kded: PowerDevil SuspendS> jun 19 12:04:15 Arch-PC kdeinit5[485]: Module "kded_touchpad" was not fo> jun 19 12:04:23 Arch-PC flameshot[575]: QProcess: Destroyed while proces> jun 19 12:04:24 Arch-PC org_kde_powerdevil[589]: powerdevil: No outputs > jun 19 12:04:24 Arch-PC org_kde_powerdevil[589]: powerdevil: Xrandr not > jun 19 12:04:25 Arch-PC backlighthelper[644]: powerdevil: no kernel back> jun 19 12:04:25 Arch-PC org_kde_powerdevil[589]: powerdevil: org.kde.pow> jun 19 12:04:25 Arch-PC org_kde_powerdevil[589]: org.kde.bluez: Cannot o> jun 19 12:04:25 Arch-PC org_kde_powerdevil[589]: powerdevil: Handle butt> jun 19 12:04:29 Arch-PC kdeinit5[482]: kf5.kded: found kded module "appe> jun 19 12:04:34 Arch-PC kwin_x11[530]: kf5.kcoreaddons.desktopparser: Pr> jun 19 12:04:35 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:04:35 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:04:37 Arch-PC plasmashell[544]: kf5.kpackage: No metadata file> jun 19 12:04:37 Arch-PC plasmashell[544]: kf5.kpackage: No metadata file> jun 19 12:04:37 Arch-PC plasmashell[544]: kf5.kpackage: No metadata file> jun 19 12:04:37 Arch-PC plasmashell[544]: trying to show an empty dialog jun 19 12:04:39 Arch-PC plasmashell[544]: Trying to use rootObject befor> jun 19 12:04:39 Arch-PC plasmashell[544]: Both point size and pixel size> jun 19 12:04:39 Arch-PC plasmashell[544]: Both point size and pixel size> jun 19 12:04:39 Arch-PC plasmashell[544]: Both point size and pixel size> jun 19 12:04:39 Arch-PC plasmashell[544]: trying to show an empty dialog jun 19 12:04:40 Arch-PC plasmashell[544]: Connecting to deprecated signa> jun 19 12:04:40 Arch-PC plasmashell[544]: file:///usr/lib/qt/qml/QtQuick> jun 19 12:04:40 Arch-PC plasmashell[544]: file:///usr/lib/qt/qml/org/kde> jun 19 12:04:40 Arch-PC plasmashell[544]: file:///usr/lib/qt/qml/QtQuick> jun 19 12:04:40 Arch-PC plasmashell[544]: file:///usr/lib/qt/qml/org/kde> jun 19 12:04:40 Arch-PC plasmashell[544]: trying to show an empty dialog jun 19 12:04:41 Arch-PC plasmashell[544]: Trying to use rootObject befor> jun 19 12:04:43 Arch-PC plasmashell[544]: Trying to use rootObject befor> jun 19 12:04:45 Arch-PC plasmashell[544]: Both point size and pixel size> jun 19 12:04:45 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:04:45 Arch-PC plasmashell[544]: trying to show an empty dialog jun 19 12:04:45 Arch-PC kdeinit5[482]: modemmanager-qt: Failed enumerati> "Unit dbus-org.freedesktop.Modem> jun 19 12:04:46 Arch-PC plasmashell[544]: KAStatsFavoritesModel::setFavo> jun 19 12:04:46 Arch-PC plasmashell[544]: Entry is not valid "kontact.de> jun 19 12:04:46 Arch-PC plasmashell[544]: Entry is not valid "ktp-contac> jun 19 12:04:46 Arch-PC plasmashell[544]: Entry is not valid "kontact.de> jun 19 12:04:46 Arch-PC plasmashell[544]: Entry is not valid "ktp-contac> jun 19 12:04:47 Arch-PC plasmashell[544]: trying to show an empty dialog jun 19 12:04:48 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:04:48 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:04:48 Arch-PC plasmashell[544]: org.kde.plasma.pulseaudio: No > jun 19 12:04:59 Arch-PC systemd-coredump[811]: Process 750 (baloo_file_e> Stack trace of thread 750: #0 0x00007f409f9e986b ra> #1 0x00007f409f9d440e ab> #2 0x00007f409f351ce2 n/> #3 0x00007f409f346c75 n/> #4 0x00007f409f347e9b n/> #5 0x00007f409f348129 n/> #6 0x00007f409f349d54 n/> #7 0x00007f409f34dfda md> #8 0x00007f409f34f64c n/> #9 0x00007f40a21762ef _Z> #10 0x00007f40a219af84 _Z> #11 0x00005626e1669603 n/> #12 0x00007f40a039fcc7 n/> #13 0x00007f40a039438b _Z> #14 0x00007f40a10dda74 _Z> #15 0x00007f40a10e5341 _Z> #16 0x00007f40a0369cb9 _Z> #17 0x00007f40a03bc40a _Z> #18 0x00007f40a03bcc92 n/> #19 0x00007f409cb60368 g_> #20 0x00007f409cb605b1 n/> #21 0x00007f409cb6063e g_> #22 0x00007f40a03bd039 _Z> #23 0x00007f4098562722 n/> #24 0x00007f40a036894c _Z> #25 0x00007f40a0370c46 _Z> #26 0x00005626e1666d70 n/> #27 0x00007f409f9d606b __> #28 0x00005626e1666eaa _s> Stack trace of thread 773: #0 0x00007f409faa0ea9 __> #1 0x00007f409924c180 n/> #2 0x00007f409924de4b xc> #3 0x00007f40984cd22a n/> #4 0x00007f40a01bbb45 n/> #5 0x00007f409f12b075 st> #6 0x00007f409faab53f __> Stack trace of thread 809: #0 0x00007f409faa0ea9 __> #1 0x00007f409cb60523 n/> #2 0x00007f409cb6063e g_> #3 0x00007f40a03bd039 _Z> #4 0x00007f40a036894c _Z> #5 0x00007f40a01b1a99 _Z> #6 0x00007f40a1ce1976 n/> #7 0x00007f40a01bbb45 n/> #8 0x00007f409f12b075 st> #9 0x00007f409faab53f __> jun 19 12:05:24 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:05:24 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:05:51 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:05:51 Arch-PC plasmashell[544]: file:///usr/share/plasma/plasm> jun 19 12:06:15 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:06:27 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:07:01 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:07:02 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:07:22 Arch-PC org_kde_powerdevil[589]: UdevQt: unhandled devic> jun 19 12:07:22 Arch-PC kdeinit5[482]: UdevQt: unhandled device action "> jun 19 12:07:22 Arch-PC baloo_file[539]: UdevQt: unhandled device action> jun 19 12:07:22 Arch-PC plasmashell[544]: UdevQt: unhandled device actio> jun 19 12:07:22 Arch-PC org_kde_powerdevil[589]: UdevQt: unhandled devic> jun 19 12:07:22 Arch-PC kdeinit5[482]: UdevQt: unhandled device action "> jun 19 12:07:22 Arch-PC baloo_file[539]: UdevQt: unhandled device action> jun 19 12:07:22 Arch-PC plasmashell[544]: UdevQt: unhandled device actio> jun 19 12:07:22 Arch-PC upowerd[416]: unhandled action 'bind' on /sys/de> jun 19 12:07:22 Arch-PC upowerd[416]: unhandled action 'bind' on /sys/de> jun 19 12:07:23 Arch-PC baloo_file[539]: QObject::connect: invalid null > jun 19 12:07:23 Arch-PC kdeinit5[482]: QObject::connect: invalid null pa> jun 19 12:07:23 Arch-PC baloo_file[539]: QObject::connect: invalid null > jun 19 12:07:23 Arch-PC kdeinit5[482]: QObject::connect: invalid null pa> jun 19 12:07:24 Arch-PC kernel: FAT-fs (sdd1): Volume was not properly u> jun 19 12:07:24 Arch-PC kdeinit5[482]: QObject::connect: invalid null pa> jun 19 12:08:08 Arch-PC kwin_x11[530]: qt.qpa.xcb: QXcbConnection: XCB e> jun 19 12:08:27 Arch-PC plasmashell[544]: qt.qpa.xcb: QXcbConnection: XC> jun 19 12:08:28 Arch-PC plasmashell[544]: qt.qpa.xcb: QXcbConnection: XC> jun 19 12:08:28 Arch-PC plasmashell[544]: qt.qpa.xcb: QXcbConnection: XC> jun 19 12:08:39 Arch-PC plasmashell[544]: qt.qpa.xcb: QXcbConnection: XC> jun 19 12:09:04 Arch-PC plasmashell[544]: qt.qpa.xcb: QXcbConnection: XC> lines 165-180/180 (END)
Maximize Konsole window before marking a log output. At the moment everything is cut in the middle. Not sure what is the etiquette of this bugtracker? Maybe it's better to save output to pastebin/hastebin and post a link? I would check times. Just plug in something and then check journal if in that time showed something suspicious. Did you plugged in something at times showed in the log? However the fact that Gnome session mounts everything correctly suggest some bug on Plasma level. It looks like something bad is happening with baloo. It's worth to check it out (refresh baloo, check configuration, etc.) although it has nothing to do with the problem, although... this unhandled device action may be somewhat connected? Interesting line is: kernel: FAT-fs (sdd1): Volume was not properly u> I hope that someone more knowledgeable will chip in. Actually those sort of problems are better to be posted on forums where more users can find them and answer, while devs should take care of general Plasma and KDE bugs. Maybe there are better ways to look for mounting errors.
Created attachment 113434 [details] journalctl -b -p4 I connected a pendrive to usb port on jun 19 13:23:36.
journalctl -b -p3 -- Logs begin at Tue 2018-02-27 15:13:40 -03, end at Tue 2018-06-19 13:23:58 -03. -- jun 19 12:03:44 Arch-PC nmbd[375]: [2018/06/19 12:03:43.997482, 0] ../source3/nmbd/asyncdns.c:158(start_async_dns) jun 19 12:03:44 Arch-PC nmbd[375]: started asyncdns process 380 jun 19 12:03:44 Arch-PC nmbd[375]: [2018/06/19 12:03:44.418906, 0] ../lib/util/become_daemon.c:138(daemon_ready) jun 19 12:03:44 Arch-PC nmbd[375]: daemon_ready: STATUS=daemon 'nmbd' finished starting up and ready to serve connections jun 19 12:03:45 Arch-PC smbd[382]: [2018/06/19 12:03:45.940600, 0] ../lib/util/become_daemon.c:138(daemon_ready) jun 19 12:03:45 Arch-PC smbd[382]: daemon_ready: STATUS=daemon 'smbd' finished starting up and ready to serve connections jun 19 12:04:59 Arch-PC systemd-coredump[811]: Process 750 (baloo_file_extr) of user 1000 dumped core. Stack trace of thread 750: #0 0x00007f409f9e986b raise (libc.so.6) #1 0x00007f409f9d440e abort (libc.so.6) #2 0x00007f409f351ce2 n/a (liblmdb.so) #3 0x00007f409f346c75 n/a (liblmdb.so) #4 0x00007f409f347e9b n/a (liblmdb.so) #5 0x00007f409f348129 n/a (liblmdb.so) #6 0x00007f409f349d54 n/a (liblmdb.so) #7 0x00007f409f34dfda mdb_cursor_del (liblmdb.so) #8 0x00007f409f34f64c n/a (liblmdb.so) #9 0x00007f40a21762ef _ZN5Baloo10DocumentDB3delEy (libKF5BalooEngine.so.5) #10 0x00007f40a219af84 _ZN5Baloo16WriteTransaction14removeDocumentEy (libKF5BalooEngine.so.5) #11 0x00005626e1669603 n/a (baloo_file_extractor) #12 0x00007f40a039fcc7 n/a (libQt5Core.so.5) #13 0x00007f40a039438b _ZN7QObject5eventEP6QEvent (libQt5Core.so.5) #14 0x00007f40a10dda74 _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5) #15 0x00007f40a10e5341 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5) #16 0x00007f40a0369cb9 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5) #17 0x00007f40a03bc40a _ZN14QTimerInfoList14activateTimersEv (libQt5Core.so.5) #18 0x00007f40a03bcc92 n/a (libQt5Core.so.5) #19 0x00007f409cb60368 g_main_context_dispatch (libglib-2.0.so.0) #20 0x00007f409cb605b1 n/a (libglib-2.0.so.0) #21 0x00007f409cb6063e g_main_context_iteration (libglib-2.0.so.0) #22 0x00007f40a03bd039 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #23 0x00007f4098562722 n/a (libQt5XcbQpa.so.5) #24 0x00007f40a036894c _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #25 0x00007f40a0370c46 _ZN16QCoreApplication4execEv (libQt5Core.so.5) #26 0x00005626e1666d70 n/a (baloo_file_extractor) #27 0x00007f409f9d606b __libc_start_main (libc.so.6) #28 0x00005626e1666eaa _start (baloo_file_extractor) Stack trace of thread 773: #0 0x00007f409faa0ea9 __poll (libc.so.6) #1 0x00007f409924c180 n/a (libxcb.so.1) #2 0x00007f409924de4b xcb_wait_for_event (libxcb.so.1) #3 0x00007f40984cd22a n/a (libQt5XcbQpa.so.5) #4 0x00007f40a01bbb45 n/a (libQt5Core.so.5) #5 0x00007f409f12b075 start_thread (libpthread.so.0) #6 0x00007f409faab53f __clone (libc.so.6) Stack trace of thread 809: #0 0x00007f409faa0ea9 __poll (libc.so.6) #1 0x00007f409cb60523 n/a (libglib-2.0.so.0) #2 0x00007f409cb6063e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f40a03bd039 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #4 0x00007f40a036894c _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #5 0x00007f40a01b1a99 _ZN7QThread4execEv (libQt5Core.so.5) #6 0x00007f40a1ce1976 n/a (libQt5DBus.so.5) #7 0x00007f40a01bbb45 n/a (libQt5Core.so.5) #8 0x00007f409f12b075 start_thread (libpthread.so.0) #9 0x00007f409faab53f __clone (libc.so.6) jun 19 13:13:22 Arch-PC kernel: usb usb1-port12: Cannot enable. Maybe the USB cable is bad? jun 19 13:13:23 Arch-PC kernel: usb usb1-port12: Cannot enable. Maybe the USB cable is bad? jun 19 13:13:24 Arch-PC kernel: usb usb1-port12: Cannot enable. Maybe the USB cable is bad? jun 19 13:13:25 Arch-PC kernel: usb usb1-port12: Cannot enable. Maybe the USB cable is bad? jun 19 13:13:25 Arch-PC kernel: usb usb1-port12: unable to enumerate USB device jun 19 13:18:19 Arch-PC kernel: usb 1-12: device descriptor read/64, error -110 jun 19 13:18:53 Arch-PC kernel: sd 6:0:0:0: [sdd] No Caching mode page found jun 19 13:18:53 Arch-PC kernel: sd 6:0:0:0: [sdd] Assuming drive cache: write through
(In reply to Michał Dybczak from comment #70) > Maximize Konsole window before marking a log output. At the moment > everything is cut in the middle. Much easier, just redirect the output from journalctl: $> journalctl > log.txt
From journalctl most striking to me were: UdevQt: unhandled device action "unbind" This may not be the same but check this out: https://bbs.archlinux.org/viewtopic.php?id=236289 Solution there was to reinstall the kernel or try a different one. Also: Some data may be corrupt. Please run fsck. -> self explanatory.
ok, "Some data may be corrupt" was gone after fsck command. Reinstall the kernel did not solve the problem. I installed the kernel-lts for test purposes and got the same result. There is something wrong with my system, but probably it's not a problem with kde software. I will use gnome-disks as workaround. I think we can close this bug.
Cool. Is anyone else still experiencing this bug? If so, please speak up and we'll re-open it. Thanks!
I may be experiencing it with Kubuntu 19.04. I have a second hard drive with ext4 partition. The partition is not mounted until I click on it in Dolphin.
(In reply to Brylie Christopher Oxley from comment #77) > I may be experiencing it with Kubuntu 19.04. I have a second hard drive with > ext4 partition. The partition is not mounted until I click on it in Dolphin. Hi, Brylie I had this problem with an external hard drive that was ext4 also not on Ubuntu or any derivative it's for a media player that runs Debian but this may help. Open up the good old terminal type in $lsblk that will last all your drives if you see it in there try this $ sudo fsck -y /dev/xxx the XXX is where you put your drive in so if your drive is let's say sda1 it will look like so $ sudo fsck -y /dev/sda1 Hopefully that will help you. To get it back to Auto Mount your data will still be there. Bruce
*** Removed by KDE Sysadmin for violation of community policies ***
I'm still experiencing this bug with Solus Plasma edition. I am experiencing what was described in 391235 - that devices set to automount in settings are not automatically mounted. When I plug them into my laptop, I am prompted for an action to take (mount, mount and open with file manager, etc).