Can't mount USB drive in FC14

[jcrowley3]

vfs.usermount did not work on Fedora -- is this a BSD only fix?

The logout/login again won't work for us. We're virtualizing USB over usbip, so if you logout the device is dismounted, then remounted again when you login, and you are back in the same spot.

Does anyone have any other suggestions? This is really debilitating for the service we're trying to launch.

[Gitchimakwa]

I wasn't clear in my previous post.

I didn't have to log out. I just had to get far enough in the "switch user" process to cancel, yet be required to log in to my running session.

All the procs were still running - so unless there are unmounts taking place behind the scenes, it may work.

[jcrowley3]

Will have to scratch my head on that a bit ....

We are bringing our user into a VNC session from our client device, so we're actually initiating the session and doing the login. Maybe there is a game we can play along the lines you proposed.

.... but that being said, would much, much rather fix the root problem. In previous versions this worked like a charm -- our user plugs in the flash drive, we detect and mount it (thru udev), and up pops Nautilus already positioned to show the files on the drive. Now we suddenly get the Not Authorized popup, and aren't even sure from where it's being generated. Tried all the tricks of making sure the mount point is owned by our user, etc, etc and still can't get around it. Some other threads were saying that the ConsoleKit is the source, but have not had time to track it down.

Best guess is that it occurs because we are coming in remotely via VNC, so there is no local "seat", but this is also speculation at the moment.

The bottom line is that it's a crippling problem, needs to be fixed, and we probably don't have the expertise here to dig into enough subsystems to fix it. Having it go from a great working feature to not working just by upgrading to the latest release of Fedora is a real bummer.

[alreaud]

After using preupgrade-cli to upgrade to Fedora 14 from Fedora 13, I had this same nuisance where a user could only mount USB sticks and DVD drives as root, not as themselves. Yum also had to be used from the root account and could not be used via the yum GUI from a user account, as it didn't ask for the root password.

Looking at /var/log/messages, I started seeing errors in the form:

Jun 11 19:01:42 HCTMAIN kernel: [ 921.015360] type=1400 audit(1307840502.004:25911): avc: denied { read } for pid=1157 comm="polkitd" name="ConsoleKit" dev=dm-1 ino=16757 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:consolekit_var_run_t:s0 tclass=dir

Jun 11 19:01:46 HCTMAIN kernel: [ 925.013952] type=1400 audit(1307840506.002:25912): avc: denied { read } for pid=1157 comm="polkitd" name="ConsoleKit" dev=dm-1 ino=16757 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:consolekit_var_run_t:s0 tclass=dir

Attempting to correct the problem via use of semanage, fixfiles, and restorecon failed to fix the problem, though in the process it was found that there are two other areas where selinux has the wrong file label for ConsoleKit files also.

semanage fcontext -a -t policykit_t "/var/run/console-kit-deamon.pid" appeared to work.
restorecon -R -v /var/run/console-kit-deamon.pid fails for permission denied, as root.
fixfiles -f relabel "/var/run" fails on the above file for permission denied, as root.

What fixed the problem was:

1. Changing some of the File Labels of the ConsoleKit entries to have the policykit_t.
2. Changing the Process Domain for policykit to Permissive.

After the above, a plain user could mount a usb stick or camera. See http://happycattech.com/content/fedo...ng-usb-and-dvd for the images of system-config-selinux File Label and Process Domain tabs.

This solution is not optimal, and the exact policy entry that is in question needs to be fixed, rather than the shotgun method of disabling the process domain.

June 12, 2011 - Found that selinux had been updated and is currently in Quality Assurance. But the testing repo had the update available regardless. There are still issues with selinux as I'm getting different avc errors, but this one appears fixed in as far as the logs show. See bug 703596 at https://bugzilla.redhat.com/show_bug.cgi?id=703596

[jcrowley3]

Understand what you are saying, but SELinux is Disabled on our test server and still cannot mount a USB drive.

Is there any debug setting that we can turn on to tell us what module is returning the non-authorization? Have tried searching the kernel source tree for that particular message with no luck.

Still a major problem!

[alreaud]

All I can think of at the moment is the logs, such as /var/log/messages, etc. That's were I discovered my problem, and a hint towards the solution.

[xtian]

I am post-install configuring Fedora 15 from Fedora 11. I frequently use my laptop as a webdev test box and therefore prefer to boot to run level 3. Fedora 15 has a file,

 /etc/systemd/system/default.target

it uses to point to the desired default run level.

I am using XFCE. The net result of booting to run level 3 and launching XFCE from the command line was this same problem (though I don't use selinux or GUI yum). Changing the default back to run level 5 fixed the problem.

So the question is, what didn't happen with the command startxfce4?