Description of problem: systemd-udevd starts generating error messages once mobile phone is plugged to charge. Feb 4 20:47:50 dhcp-30-172 systemd-udevd[18968]: Failed to set security context (null) for /dev/disk: File exists Version-Release number of selected component (if applicable): rpm -q systemd systemd-197-1.fc18.1.x86_64 rpm -q selinux-policy selinux-policy-3.11.1-73.fc18.noarch How reproducible: 100% Steps to Reproduce: 1.Plug the phone using USB cable 2.Check /var/log/messages, it also increases CPU temperature. Actual results: Feb 4 20:47:50 dhcp-30-172 kernel: [397881.377247] scsi 9:0:0:0: Direct-Access SEMC Mass Storage 0100 PQ: 0 ANSI: 4 Feb 4 20:47:50 dhcp-30-172 kernel: [397881.380881] sd 9:0:0:0: Attached scsi generic sg2 type 0 Feb 4 20:47:50 dhcp-30-172 kernel: [397881.384606] sd 9:0:0:0: [sdb] Attached SCSI removable disk Feb 4 20:47:50 dhcp-30-172 systemd-udevd[18968]: Failed to set security context (null) for /dev/disk: File exists Feb 4 20:47:50 dhcp-30-172 systemd-udevd[18968]: Failed to set security context (null) for /dev/disk/by-path: File exists Feb 4 20:47:50 dhcp-30-172 systemd-udevd[18968]: Failed to set security context (null) for /dev/disk: File exists Feb 4 20:47:50 dhcp-30-172 systemd-udevd[18968]: Failed to set security context (null) for /dev/disk/by-path: File exists Feb 4 20:47:50 dhcp-30-172 systemd-udevd[18968]: Failed to set security context (null) for /dev/disk: File exists Expected results: Additional info: disabling selinux (setenforce 0) stops the error messages
Happens for me with every usb mass storage device.
Feb 17 18:38:14 pundit systemd-udevd[27155]: Failed to set security context (null) for /dev/v4l: File exists Feb 17 18:38:14 pundit systemd-udevd[27155]: Failed to set security context (null) for /dev/v4l/by-id: File exists It happens with usb webcam and input devices, probably selinux policy issue see http://forums.fedoraforum.org/showthread.php?p=1634011
+1 USB mass storage, msdos partition table, four primary partitions. Over two thousand Failed to set security context (null) for /dev/disk: File exists or Failed to set security context (null) for /dev/disk/by-path: File exists messages. # rpm -q systemd systemd-197-1.fc18.1.x86_64 # rpm -q selinux-policy-targeted selinux-policy-targeted-3.11.1-78.fc18.noarch # uname -r 3.7.7-201.fc18.x86_64 Partitions appear in logged in user desktop/nautilus, but logged in user can only mount as root
Tried "restorecon -r -v /dev" to see if this is a labeling problem. Got this: restorecon reset /dev/disk/by-uuid/400A-8D10 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/disk/by-id/usb-SanDisk_Cruzer_Glide_4C532000021126113572-0:0 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/bsg/4:0:0:0 context system_u:object_r:device_t:s0->system_u:object_r:scsi_generic_device_t:s0 restorecon reset /dev/block/8:17 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/block/8:16 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/char/21:2 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/char/252:2 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 restorecon reset /dev/char/189:3 context system_u:object_r:udev_var_run_t:s0->system_u:object_r:device_t:s0 But it didn't help. Running "udevadm trigger" produced hundreds more of the same messages in /var/log/messages, and still did not mount the device.
I'm running selinux-policy-3.11.1-78.fc18.noarch, and the problem seems to have been fixed.
Same issue with my ebook. I have selinux-policy-3.11.1-79.fc18 installed. I tried "restorecon -r -v /dev", but it did not help. Disabling selinux via "setenforce 0" is my workaround for now (no more error messages and my usb device is mounted correctly).
I had the same experience as Bruno. The problem is gone for me with selinux-policy-3.11.1-79.fc18 (didn't try with 3.11.1-78).
I'm afraid the problem is not solved. I've tried using a USB mass storage and the issue continues :(
My system just started doing this. strace on systemd-udevd says: stat("/dev/disk/by-path", 0x7fffa005c000) = -1 ENOENT (No such file or directory) mkdir("/dev", 0755) = -1 EEXIST (File exists) (in a loop)
I get this problem, after selinux-policy package is updated when I connect usb drive and it usually disappears after reboot.
After almost every weekend mouse is locked and I have to press Ctrl-Alt-Backspace. Hundreds of terminal lines appear in syslog (see below). Of course mouse remain locked and a reboot is required. After reboot everything works correctly. ... [431801.104523] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists [431801.104579] systemd-udevd[15674]: Failed to set security context (null) for /dev/input: File exists [431801.104602] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists [431801.104656] systemd-udevd[15674]: Failed to set security context (null) for /dev/input: File exists [431801.104680] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists [431801.104736] systemd-udevd[15674]: Failed to set security context (null) for /dev/input: File exists [431801.104779] systemd-udevd[15674]: Failed to set security context (null) for /dev/input/by-id: File exists ...
I forgot to mention that the mouse works properly in text terminals, only X does not have functional mouse.
Try autorelabeling and see if it fixes your issue anyway moving against selinux they will just throw it back if it turns out not to be a policy issue.
No this looks like a problem in systemd-udev. probably not a labeling issue.
So, I think the same thing was happening on my system and it started a couple weeks ago and just stopped today after a reboot. If it was a change to selinux policy, then it must have been a very very recent update. But, udevd seems to be doing the right thing with USB disks on my system, now. Current policy rpm: selinux-policy-targeted-3.11.1-81.fc18.noarch
*** This bug has been marked as a duplicate of bug 909826 ***