Created attachment 191034 [details]
Start Menu (Bigger)

Can't reproduce on KDE Linux, which has systemd 260

What's the output of "qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanPowerOff"?

It returns 'true'
I tried to run it in .bash_profile to output to a file and it still returns 'true'. Don't know if I can run that command earlier in the session startup than that.

I will try to explain more. Previously I was using my non-system drives as noauto in fstab, because I thought I could gain some boot time by mounting them with kded (there's no difference after all). I removed the noauto and it fixed the problem. Then I enabled autologin in plasma-login and it's back. It seems it's related to having the session start as early as possible with many plasma services enabled(?)

Try to set autologin as well, krdp, etc

How can I see verbose logs of plasmashell?

I meant to say it outputs 'yes', not 'true'

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

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

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

(In reply to Nicolas Fella from comment #3)
> What's the output of "qdbus --system org.freedesktop.login1
> /org/freedesktop/login1 org.freedesktop.login1.Manager.CanPowerOff"?

I am experiencing the same bug and ran this as well.

It also came back as "yes."

I am also experiencing this bug which is very annoying

Setting to CONFIRMED since multiple people are affected

Days ago after a reboot it disappeared. After 2-3 reboots it returned.

(In reply to Marco Brancalion from comment #12)
> Days ago after a reboot it disappeared. After 2-3 reboots it returned.

This bug has not subsided for me personally


For more detail it seems to be with all plasmoids as the user switcher also doesn't work anymore for these options. I've also found the only option given on the lock screen is now "switch user" although I'm not sure if I'm misremembering (maybe that was the only option? But I swore there were more) 

CTRL+ALT+DEL still works and I can shutdown from there but it is not my preferred method

(In reply to Marco Brancalion from comment #12)
> Days ago after a reboot it disappeared. After 2-3 reboots it returned.

For me, it did that then disappears again later.

I can reproduce this bug by doing the following.
Have a USB HDD (in my case connected).
In systemsettings under Datenträger & Kameras (likely drives & cameras) set an automount on login and device connect for this drive.
Reboot 
Login
Power buttons like Standy, Restart, Shutdown are gone.
Logout 
Log in
Buttons are back.

Remove the automount in systemsettibgs
Reboot
Login
Buttons are working fine

I'm on 6.6.4 also on Arch Linux.

On fresh and clean install Arch width Plasma 6.6.3, the bug is not reproducible, even if you enable automatic mounting of disks in the settings. Maybe somthing with old config and version? Or it maybe something with system file permissions.

(In reply to Kevin from comment #15)
> I can reproduce this bug by doing the following.

Can you reproduce this with a brand new user, keeping all default settings except for the automount?

(In reply to xniksysx from comment #16)
> On fresh and clean install Arch width Plasma 6.6.3, the bug is not
> reproducible, even if you enable automatic mounting of disks in the
> settings. Maybe somthing with old config and version? Or it maybe something
> with system file permissions.

I'm on an arch derivative as well (Garuda) and also have multiple drives (internal) automount. When I get the chance I'll try disabling auto mounting and see if the issue changes p

Thanks everyone. I'll set this as NEEDSINFO so it will remind us in 2 weeks if there hasn't been a response.

(In reply to kde.absence002 from comment #18)
> (In reply to xniksysx from comment #16)
> > On fresh and clean install Arch width Plasma 6.6.3, the bug is not
> > reproducible, even if you enable automatic mounting of disks in the
> > settings. Maybe somthing with old config and version? Or it maybe something
> > with system file permissions.
> 
> I'm on an arch derivative as well (Garuda) and also have multiple drives
> (internal) automount. When I get the chance I'll try disabling auto mounting
> and see if the issue changes p



I just tested. Turning off automount on all my drives resolved the issue

(In reply to Kevin from comment #15)
> I can reproduce this bug by doing the following.
> Have a USB HDD (in my case connected).

This particular bug I only noticed after I got a QNAP TR-004 HDD enclosure and I set one drive to automount at startup. Before I got the enclosure I had no external drives opening on startup.

(In reply to kde.absence002 from comment #20)

> I just tested. Turning off automount on all my drives resolved the issue

Thanks. 
Can you reproduce this with a brand new user, keeping all default settings except for the automount?

(In reply to TraceyC from comment #22)
> (In reply to kde.absence002 from comment #20)
> 
> > I just tested. Turning off automount on all my drives resolved the issue
> 
> Thanks. 
> Can you reproduce this with a brand new user, keeping all default settings
> except for the automount?

Simply for clarity. I assume you mean to create a new user, edit nothing and simply enable automount as to see if automount alone is the issue or of there's more configuration? It so I should be able to do so within the next 24 hours

(In reply to TraceyC from comment #17)
> (In reply to Kevin from comment #15)
> > I can reproduce this bug by doing the following.
> 
> Can you reproduce this with a brand new user, keeping all default settings
> except for the automount?

Yes I can.

I also tried installing Cachyos inside a VM to make sure that it's not related to any configuration I did inside my Arch install.
Same exact behavior on Cachyos. Created a new user there as well just to be sure.

It only happens when the drive actually gets mounted.
If I disconnect it before reboot the behavior vanishes.

I tried with USB 3 HDD enclosures and a SanDisk Ultra USB 3 thumb drive.

My initial assumption it might be x11 session related also turned out to be not the case because cachy is running on Wayland compared to my personal installation (need x11 for remote desktop).

(In reply to Kevin from comment #24)
Thanks for the extra troubleshooting, that's very helpful

Yesterday (2026-04-09T15:17) I upgraded my CachyOS system (including systemd 259 -> 260) through pacman and after rebooting, my shutdown-button in the kde plasma start menu was gone as well. Same thing happened on a mate's CachyOS install after he updated a couple days ago.
This bug happens on every boot and indeed goes away temporarily when logging out and back in again. 

I'm currently just using "shutdown now" as a workaround, which still works fine. Normally I'm just pressing my physical power button, which has been configured to call a shutdown through kde plasma, but that also doesn't work. So it's probably not just a GUI bug here.

Kernel: 6.19.11-1-cachyos
Desktop: KDE Plasma v: 6.6.4 tk: Qt v: N/A wm: kwin_wayland dm: 1: GDM
    v: 50.0 2: SDDM note: stopped Distro: CachyOS base: Arch Linux

I am not running any slow/external HDD devices. Just internal SSDs. Same on my mate's computer, so I'm not sure if this really is a factor here.

'qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanPowerOff' returns:
yes

Unable to reproduce this on my Garuda Linux (which is also 'Arch btw' based, I couldn't resist kekw)

Systemd 260.1-1
Which got updated 5days ago as per my pacman log
[2026-04-05T16:47:24+0200] [ALPM] upgraded systemd (259.3-1 -> 260.1-1)

And I'm one of the most techgeek technerds on the earth, and I use my PC nonstop (like I mean nonstop, it's like I get IT by infusion lol).

Operating System: Garuda Linux 
KDE Plasma Version: 6.6.4
KDE Frameworks Version: 6.25.0
Qt Version: 6.11.0
Kernel Version: 6.19.11-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6500 CPU @ 3.20GHz
Memory: 16 GiB of RAM (15.6 GiB usable)
Graphics Processor: NVIDIA GeForce GTX 1050 Ti
Manufacturer: MSI
Product Name: MS-7972
System Version: 2.0

> I just tested. Turning off automount on all my drives resolved the issue

I just went into my disk management utility (GNOME-Disks) and selected the drive I have automount in question and went to "Edit Mount Options" and turned off the "User Session Defaults" and selected it to automount that way (I used to have to do this for an internal drive I had that had trouble automounting.)

Gave the system a reboot (which normally would cause the icons in question to disappear) and both the Power and Restart icons remained.

Will have to use my computer for a bit to see if this is an effective way to sidestep this error.

I would like to have this drive automount as it is a drive I interact with in almost every session on my computer so I hope this works.

(In reply to kde.absence002 from comment #23)
> (In reply to TraceyC from comment #22)
> > (In reply to kde.absence002 from comment #20)
> > 
> > > I just tested. Turning off automount on all my drives resolved the issue
> > 
> > Thanks. 
> > Can you reproduce this with a brand new user, keeping all default settings
> > except for the automount?
> 
> Simply for clarity. I assume you mean to create a new user, edit nothing and
> simply enable automount as to see if automount alone is the issue or of
> there's more configuration? It so I should be able to do so within the next
> 24 hours



Created a new user, I tried both Standard and Administrator new users. Added the requisite plasmoids and enabled automount. The issue did not show up. So I returned to my main user an enabled automount again to see if the issue would return if I did on my main user. The issue returned on my main. 

Not sure why automount has no effect on the new user both Standard and Administrator but on my original user, automount breaks the plasmoid

(In reply to kde.absence002 from comment #29)
> Created a new user, I tried both Standard and Administrator new users. Added
> the requisite plasmoids and enabled automount. The issue did not show up. So
> I returned to my main user an enabled automount again to see if the issue
> would return if I did on my main user. The issue returned on my main. 
> 
> Not sure why automount has no effect on the new user both Standard and
> Administrator but on my original user, automount breaks the plasmoid

Thanks for troubleshooting that. This suggests that your existing user account has some configuration in it that's causing this issue. Which means that it's likely a case of old, previously-supported configuration data being unsupported today and interacting poorly with modern code.

If you could identify which exact thing is causing it, we can determine which of those options it is. If not, then I don't think we'll be able to make any further progress here unfortunately. Your best bet is to diff the KDE related rc files under ~/.config/ between the new user and your regular user.

(In reply to TJ from comment #28)
> > I just tested. Turning off automount on all my drives resolved the issue
> 
> I just went into my disk management utility (GNOME-Disks) and selected the
> drive I have automount in question and went to "Edit Mount Options" and
> turned off the "User Session Defaults" and selected it to automount that way

Have used  my computer extensively since posting this and can confirm it appears to placate the issue.  Have not had the icons disappear.

I've decided to hunt down the cause of the bug and believe I have found it

Garuda Linux / Arch, systemd 260.1-1-arch, Plasma 6.6.4


I can reproduce without autologin (using manual login via SDDM is sufficient.)
My fstab contains no external drives; secondary drives are handled entirely by kded automount. The bug occurs despite this.
The bug does not occur on a freshly created user account with the same automount setting, pointing to a user config difference.
After bisecting kded modules via ~/.config/kded5rc, I narrowed it down to plasmavault's load order:

[Module-plasmavault] omitted from kded5rc (default) → bug occurs
[Module-plasmavault] autoload=true → bug occurs
[Module-plasmavault] autoload=false → bug is fixed

Notably, plasmavault loads regardless of the setting — qdbus6 org.kde.kded6 /kded org.kde.kded6.loadedModules shows it present in all three cases. This suggests the explicit false entry delays plasmavault's initialization relative to other modules, which is enough to prevent the race condition (which is what my guess is but I'm no programmer) 


As seen if i run
qdbus6 org.kde.kded6 /kded org.kde.kded6.loadedModules | sort
appmenu
audioshortcutsservice
baloosearchmodule
bluedevil
browserintegrationflatpakintegrator
desktopnotifier
device_automounter
devicenotifications
donationmessage
freespacenotifier
gtkconfig
kameleon
kded_accounts
kded_bolt
kded_plasma_welcome
keyboard
ktimezoned
kwrited
lookandfeelautoswitcher
mprisservice
networkmanagement
oom-notifier
plasma_accentcolor_service
plasma-session-shortcuts
plasmavault
printmanager
remotenotifier
smart
smbwatcher
statusnotifierwatcher
wacomtablet
wpad-detector

plasmavault is still a loaded module despite explicitly setting it to false.

Potential workaround for affected users: Add the following to ~/.config/kded5rc:
[Module-plasmavault]
autoload=false

I was able to make some good progress on this. Hope you can now reproduce this issue on your systems.

So in my case it doesn't have anything to do with automount or autologin. On my system, automount isn't enabled through KDE. Autologin can be toggled on or off and doesn't change the problem. I still see no shutdown nor reboot button. "plasmavault" isn't even loaded for me, so this workaround:
"[Module-plasmavault]
autoload=false"
doesn't change anything.

But after I created a new user and thought about my individual system init process, I was able to find the cause of this issue on my system. It's a script that I use to sync files with rclone. It runs as a systemd service and uses systemd-inhibit to inhibit sleep, idle and shutdown whenever the sync process is active. In the past this didn't cause any issues, but now it has. I was able to create a minimal setup that reproduces this problem for me. Here's how:
1. create a fresh standard account
2. save this simple sh script somewhere (not sure if the sleep calls are really necessary here):
#!/bin/bash

inhibit() {
  echo "inhibit started"
  systemd-inhibit --why="inhibit TEST" sleep infinity &
  sleep 2
}

echo "inhibiting ..."
inhibit

while true; do
  sleep 5
  inhibit
done
---------------
3. install it as a simple systemd service, so that systemd-inhibit blocks 'shutdown'
4. reboot and see the shutdown/reboot buttons disappear
5. changing the --what value to "sleep:idle" (default is sleep:idle:shutdown) will show the shutdown/reboot buttons again after a reboot, so, as you'd expect, only the shutdown inhibition seems relevant here

It seems to me that plasmashell (or whatever component is responsible) sees the shutdown inhibition on startup and gets stuck in this state. My original rclone-sync script only inhibits during syncs, so I would have expected that plasmashell would check again periodically or event-based, if the shutdown inhibition is still active. But in any case I'd expect the shutdown/reboot buttons to always be available. These buttons should always be visible and clickable and on click ask the user if he wants to override an active shutdown inhibition. Much like 'systemctl reboot' alerts the user to this fact and suggests 'systemctl reboot -i' to override it.

Thanks for the investigation, very useful.

This can easily be reproduced by running "systemd-inhibit --why="inhibit TEST" sleep infinity" and then "plasmashell --replace".

The release notes for systemd 260 have

>The org.systemd.login1.Manager D-Bus interface has a minor API break.
>The CanPowerOff(), CanReboot(), CanSuspend(), etc. family of methods
> have introduced new return values which may break downstream
>consumers such as desktop environments. The new return values more
>precisely communicate the status of inhibitors: 'inhibited',
>'inhibitor-blocked', and 'challenge-inhibitor-blocked'. This allows
>desktops to differentiate between system administrator policy and
>temporary restrictions imposed by inhibitors.

so if the status is any of the new values at startup the buttons will be missing

Yep that is surely the cause

I would like to add another issue I noticed today, don't know if I should open a new bug report since it's related to this systemd breaking change as well. 

I had set up the system to go to sleep after 15min of inactivity or when the physical power button. When I don't have the power buttons in the start menu this doesn't work

Again restarting plasmashell / logging out and back in fix the issue

Created attachment 191506 [details]
Power Management doesn't have sleep option

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

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

Just adding to this thread that the bug reached debian-testing KDE Plasma too.

$systemctl --version
systemd 260 (260.1-1)

$plasmashell -v
plasmashell 6.6.3

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6546

Git commit 07750c8a7cc89d532ec852a677772b0402a16ba8 by Nicolas Fella.
Committed on 02/05/2026 at 12:21.
Pushed by nicolasfella into branch 'master'.

libkworkspace: Handle new states from logind

systemd 260 introduces new states for CanReboot/CanPoweroff/etc

We need to adjust our code to not trip over those

This is a bit of a hotfix, ideally we would properly indicate in the UI that a given action is temporarily inhibited

M  +3    -1    libkworkspace/sessionmanagementbackend.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/07750c8a7cc89d532ec852a677772b0402a16ba8

Git commit 8f6d71715a70e5c73d322619163dce738993724b by Nicolas Fella.
Committed on 02/05/2026 at 14:53.
Pushed by nicolasfella into branch 'Plasma/6.6'.

libkworkspace: Handle new states from logind

systemd 260 introduces new states for CanReboot/CanPoweroff/etc

We need to adjust our code to not trip over those

This is a bit of a hotfix, ideally we would properly indicate in the UI that a given action is temporarily inhibited
(cherry picked from commit 07750c8a7cc89d532ec852a677772b0402a16ba8)

M  +3    -1    libkworkspace/sessionmanagementbackend.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/8f6d71715a70e5c73d322619163dce738993724b

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

Is this considered to be fixed? 

What's the version the fix should show up - I am running 6.6.4 and I don't see any change. 
Is there anything me as a user has to do to make it work and get the shutdown buttons again?

thx, 
jhhh

Also: how can I edit typos in my comments here? 

thx, pk

As the "version fixed/implemented in" field says: 6.6.5. Which was actually released two days ago.