Can't mount USB flash drive by either KDE Device Notifier applet or udisks command with following error: $ udisks --mount /dev/sde1 Mount failed: Not Authorized Root permissions fix this, but mount point isn't readable for users. Note: I use runlevel 3 as default and such mounting by udisks works ok just after login in virtual console. It fails when launched from Konsole (KDE terminal emulator). I'm not sure udisks is the reason, but I don't know more appropriate component. Components versions: kernel-3.3.4-3.fc17.x86_64 systemd-44-8.fc17.x86_64 udisks-1.0.4-6.fc17.x86_64
--- Same problem with my (2) x86_64 systems, recently upgraded from FC16 (where everything worked OK..) KDE device notifier recognises USB disks, but gives: 'could not mount the following device. an unspecified error has occurred. Not authorized' error message. and: # udisks --mount /dev/sdl1 Mount failed: Not Authorized - udisks mount works when run as root, but this leaves the directory inaccessible to users..: # udisks --mount /dev/sdl1 Mounted /org/freedesktop/UDisks/devices/sdl1 at /media/USB3_DISK01 Tried installing _clean_ version of KDE, with new user account, but problem was still there.. Tried 'downgrading' to FC16 version of udisks (from rebuilt F16 source rpm), but no difference.. Tried different kernel versions (compiled)- no difference.. Tried mounting from Gnome3 desktop, but had to enter root password to get mount to work, and then the directory was inaccessible to users... Other USB devices (scanner and camera) are recognised - and accessed - correctly.. kdelibs-4.8.3-1.fc17.x86_64 udisks-1.0.4-6.fc17.x86_64 kernel-3.3.6-3.fc17.x86_64 Robert Gadsdon.
Additional info: Selinux is disabled, on all systems.. Just reproduced problem on FC17 ARM system, as well (Raspberry Pi): [rgadsdon@rgpi ~]$ uname -a Linux rgpi 3.1.9 #1 Wed May 16 10:00:10 BST 2012 armv6l armv6l armv6l GNU/Linux [rgadsdon@rgpi ~]$ udisks --mount /dev/sda1 Mount failed: Not Authorized Robert Gadsdon
Update: Just installed clean/new version of Fedora 17 on a test system (VMware), and on that system, # udisks --mount ... command _does_ work correctly, when running as normal user, from plain console session.. Only fails when running from X session, using KDE device-notifier or x-console command line.. Robert Gadsdon.
(In reply to comment #3) > Only fails when > running from X session, using KDE device-notifier or x-console command line.. > yeah here the same problem lots of Not authorized in kde , on Fedora 17 upgrade . udisks --mount /dev/sr0 Mount failed: Not Authorized
A workaround was found at http://www.suurmeijer.net, and has been slightly modified: Edit /usr/share/polkit-1/actions/org.freedesktop.udisks.policy as follows: <action id="org.freedesktop.udisks.filesystem-mount"> <description>Mount a device</description> <description xml:lang="da">Montér en enhed</description> <message>Authentication is required to mount the device</message> <message xml:lang="da">Autorisering er påkrævet for at montere et fil system</message> <defaults> <allow_any>no</allow_any> <allow_inactive>yes</allow_inactive> <allow_active>yes</allow_active> </defaults> </action> Change is from <allow_inactive>no</allow_inactive> to <allow_inactive>yes</allow_inactive> Applied these changes, and KDE USB mount now works. It would appear that when starting a KDE session from the command line (# startx) the session is still flagged as 'inactive' for some reason... Robert Gadsdon..
Looks like a problem with KDE, not sure what component to reassign so just closing as WORKSFORME. If you find out what component it is, feel free to reopen and ressign to that component.
please see if it is not a prelink problem as describe in https://bugzilla.redhat.com/show_bug.cgi?id=825602#c4
Reassigning to polkit-kde, I think that's the component for KDE's polkit authentication agent. Otherwise please reassign to the proper component - thanks!
*** Bug 826459 has been marked as a duplicate of this bug. ***
Does: su -c "authconfig --updateall" fix the problem?
If problems persist after implementing comment #10, please give output of: $ loginctl list-sessions if it lists your login session, post output from $ loginctl show-session <X> where <X> is your session number.
*** Bug 827093 has been marked as a duplicate of this bug. ***
# authconfig --updateall (as root) makes no difference.. (startx) KDE USB disk mount still fails, with ..'Not Authorized'.. # loginctl list-sessions SESSION UID USER SEAT 1 1000 rgadsdon seat0 # loginctl show-session 1 (from KDE konsole xterm) Id=1 Timestamp=Thu, 31 May 2012 18:03:27 +0100 TimestampMonotonic=15201092 DefaultControlGroup=name=systemd:/user/rgadsdon/1 VTNr=1 TTY=tty1 Remote=no Service=login Leader=463 Audit=1 Type=tty Class=user Active=no KillProcesses=no IdleHint=yes IdleSinceHint=300000000 IdleSinceHintMonotonic=0 Name=rgadsdon BUT: # loginctl show-session 1 (from console session only - X/KDE not running) Id=1 Timestamp=Thu, 31 May 2012 18:03:27 +0100 TimestampMonotonic=15201092 DefaultControlGroup=name=systemd:/user/rgadsdon/1 VTNr=1 TTY=tty1 Remote=no Service=login Leader=463 Audit=1 Type=tty Class=user Active=yes KillProcesses=no IdleHint=no IdleSinceHint=300000000 IdleSinceHintMonotonic=0 Name=rgadsdon and # udisks --mount .... works correctly.. .. Robert Gadsdon.
The Active=no is the problem. I guess systemd does not support startx. Does everyone seeing this issue use startx?
(In reply to comment #14) > Does everyone seeing this issue use startx? As for me, it's true.
So the problem in this case seems to be that systemd-logind gets confused by startx, so a bug in either systemd or startx. What I don't know is whether startx is involved in bug #827093 or whether it's actually separate.
$ loginctl list-sessions SESSION UID USER SEAT 1 500 binaryhat seat0 1 sessions listed. $ loginctl show-session 1 Id=1 Timestamp=Thu, 31 May 2012 10:52:26 -0400 TimestampMonotonic=42246124 DefaultControlGroup=name=systemd:/user/binaryhat/1 VTNr=1 TTY=tty1 Remote=no Service=login Leader=873 Audit=1 Type=tty Class=user Active=no KillProcesses=no IdleHint=yes IdleSinceHint=300000000 IdleSinceHintMonotonic=0 Name=binaryhat
So you have Active=no too. How are you starting KDE?
This problem was summarised in Bug 826459 (closed..) Login via 'graphical' boot (runlevel 5) - everything works correctly. Login via 'multi-user' boot (runlevel 3) - start KDE session using # startx - USB disk mount fails with 'Not Authorized'.. Robert Gadsdon.
(In reply to comment #18) > So you have Active=no too. How are you starting KDE? startx from runlevel 3.
startx is not really supported in F17. If we want to resurrect it we need it to stay on the VT it is started from instead of allocating a new one. THis should actually be realatively simple todo (and i thinkt there's a bug about that somehwere). We can't support "forking off" sessions from other sessions, due to the audit session ID being sealed off. Hence temporarily "upgrading" the tty session to a graphical one is the only sane (and relatively simple) way to go if we care about startx for longer.
(In reply to comment #16) > So the problem in this case seems to be that systemd-logind gets confused by > startx, so a bug in either systemd or startx. What I don't know is whether > startx is involved in bug #827093 or whether it's actually separate. Yeah, looks like it's either systemd-login / startx(1) problem and not KDE as I originally thought, sorry. Talking to Lennart he says startx(1) or X needs to somehow "upgrade" the existing session instead of switching to a separate VT. I've included some relevant IRC chat in [1]. I would reassign it this to startx(1) (in the xorg-x11-xinit package). [1] : <davidz> mezcalero: mmm, systemd-logind and startx, they don't work well together on f17 do they? <davidz> mezcalero: https://bugzilla.redhat.com/show_bug.cgi?id=820675 <drago01> startx is heading towards the way of the dodo <davidz> I know, but people file bugs :-) <mclasen> given that it is a stupid shell script written by some mit undergrad in the 80s, it had a pretty good run... <mezcalero> davidz: no, they don't work well together <mezcalero> davidz: there was talk about making startx "upgrade" an existing tty session to a graphical session <halfline> davidz: there's already a bug about that <mezcalero> davidz: but nobody did anything on that <davidz> mezcalero: I guess we can blame startx(1) - I mean, if startx(1) wanted, it could poke systemd-loginctl, right? <mezcalero> davidz: due to the sealing off of the audit session stuff we can't allow "forking off" sessions from other sessions <mezcalero> which means we need to to this upgrading of sessions if we want to support startx style thing <davidz> I see <mezcalero> davidz: no, startx can't poke logind <mezcalero> davidz: the fix is actually pretty easy <mezcalero> we'd need to tell X not to switch to a different VT <mezcalero> but to stay on the VT it was started from <mezcalero> it's a complex problem with a surprisingly simple solution <mezcalero> but nobody bothered to fix this in startx so far
So in short, everyone experiencing this, use a graphical login manager (such as KDM) instead of startx and your desktop will work fine.
(In reply to comment #23) > So in short, everyone experiencing this, use a graphical login manager (such > as KDM) instead of startx and your desktop will work fine. You mean using graphical.target instead of multi-user.target or just starting X with KDM, not startx? Is there any [modern] way to launch X session when started with multi-user.target?
For my particular workflow, having to login using runlevel 5 / KDM is a pain, so I'm just running with a hacked version of /usr/share/polkit-1/actions/org.freedesktop.udisks.policy, until a fix is available.. Robert Gadsdon.
(In reply to comment #24) > starting X with KDM, not startx I'm partially answering to myself: kdm can't be used as a straight startx alternative because of at least root privileges requirement. Starting it with sudo leads to authentication request despite already existing user session. Maybe it can be changed with GreeterUID in kdmrc, but I don't know the side effects of that.
*** Bug 827727 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > If problems persist after implementing comment #10, please give output of: > > $ loginctl list-sessions > > if it lists your login session, post output from > > $ loginctl show-session <X> > > where <X> is your session number. this commands could be useful in other cases , but now the command seems to be systemd-loginctl $ /bin/systemd-loginctl list-sessions SESSION UID USER SEAT 1 500 sergio seat0 1 sessions listed. $ /bin/systemd-loginctl show-session 1 Id=1 Timestamp=Sun, 03 Jun 2012 04:40:39 +0100 TimestampMonotonic=64039167 DefaultControlGroup=name=systemd:/user/sergio/1 VTNr=1 Display=:0 Remote=no Service=kdm Leader=1282 Audit=1 Type=x11 Class=user Active=yes KillProcesses=no IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=sergio in my case is working , but I don't use startx, I run in graphical mode with $ cat /etc/sysconfig/desktop DESKTOP="KDE" DISPLAYMANAGER="KDE"
(In reply to comment #28) > > this commands could be useful in other cases , but now the command seems to > be systemd-loginctl sorry I'm wrong here, loginctl exists on F17. Just doesn't exist on F16 with systemd-37-19.fc16.i686 if you have at /etc/sysconfig/prelink PRELINK_OPTS=-mR Please try: $ prelink -mR -va (as root) and reboot computer. to find out if is a prelink issue .
This issue has absolutely nothing to do with prelink, except maybe in your case, which you reported separately. What is actually happening has already been explained in comment #21 and comment #22. In addition, the workaround which you say solved the issue for you has been confirmed in (duplicate) bug #827093 NOT to fix this startx issue. Your issue seems to be completely different. Please do not spread confusion and misinformation in this bug report.
(In reply to comment #14) > The Active=no is the problem. I guess systemd does not support startx. > > Does everyone seeing this issue use startx? It seems so. It is at least for me. I was trying to figure out how I got onto this bug while reading my email. Seems my bug https://bugzilla.redhat.com/show_bug.cgi?id=827727 is a duplicate. I was also about to search for a bug about the USB issue in the first post, as that problem is also quite annoying. I thought they both could be related to a permissions issue. But I would have never thought it would be related to systemd :o >startx is not really supported in F17. It needs to get supported quickly. A lot of people still use startx. A lot of servers use RHEL. Servers certainly should not need level 5. But they still will likely need to get to a GUI for maintenance at some point in their life. A lot of people like me hate using a DM, as too much work is done on the console. This is a major issue for me on my test system. I'm with Robert in #25 concerning KDM. Using KDM is out of the question for our situation. This issue will could be a deal breaker preventing us from upgrading to F17 on any production systems until it is resolved. I don't know what other things in KDE it may affect besides logout and mounting disks.
just found a new problem which most likely is related to this bug: from konsole after startx: ping: icmp open socket: Operation not permitted You need to be root now just to do a ping . . . Yikes!!
(In reply to comment #32) > from konsole after startx: ping: icmp open socket: Operation not permitted Check iptables / SELinux maybe. I have subject issue, but ping is ok for me. Launched from Konsole after startx: $ ping -c 2 google.com PING google.com (209.85.148.139) 56(84) bytes of data. 64 bytes from fra07s07-in-f139.1e100.net (209.85.148.139): icmp_req=1 ttl=55 time=59.8 ms 64 bytes from fra07s07-in-f139.1e100.net (209.85.148.139): icmp_req=2 ttl=55 time=51.1 ms --- google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 51.121/55.470/59.819/4.349 ms
Indeed, ping does not use the systemd-logind session information, so the ping issue is separate.
(In reply to comment #34) > Indeed, ping does not use the systemd-logind session information, so the > ping issue is separate. Thanks for that info Kevin. /bin/pin and /bin/ping6 are missing capability cap_net_raw after yum upgrade from F16 on my test system: rpm -q --filecaps iputils /etc/sysconfig/rdisc /usr/bin/ping = cap_net_raw+ep /usr/bin/ping6 = cap_net_raw+ep getcap -v /bin/ping /bin/ping So capability cap_net_raw has ended up missing somehow. . . Running setcap cap_net_raw=ep /bin/ping fixes the problem: $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.489 ms I would bet this has something to do with usrmove. I wonder what else got messed up during the upgrade.
*** This bug has been marked as a duplicate of bug 806491 ***