Description of problem: after using 'su - someuser' to work as another user, emacs produces this kind of warnings when launched: $ emacs Makefile ** (emacs:30641): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. ** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. ** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. ** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. ** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. The user that runs emacs has UID 1005 on my system, so it surely is correct that emacs cannot create things below /run/user/1000/ Version-Release number of selected component (if applicable): emacs-24.2-6.fc18.x86_64 fvwm-2.6.5-3.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. use fvwm as window manager (not sure if it is important, but just to be complete) 2. open an xterm 3. issue the command "su - someuser" 4. issue the command "emacs somefile" Actual results: screaming errors/warnings in the terminal used to launch emacs, even if the editor itself seems to work just fine. Expected results: no warnings/errors should be printed when starting emacs as it seems to work properly. Additional info:
I'm seeing this too: warthog>stg edit Invoking the editor: "emacs .stgit-edit.txt" ... ** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied. dconf will not work properly. ** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied. dconf will not work properly. ** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied. dconf will not work properly. ** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied. dconf will not work properly. ** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied. dconf will not work properly. Looking in the directory: warthog>ls -l /run/user/4043/dconf total 4 -rw-------. 1 root root 2 May 22 17:44 user Which would likely be due to me doing su and then emacsing something as root. Hexdumping the file just shows a couple of zero bytes contained therein. I'm using KDE rather than fvwm.
chowning the file to myself seems to fix the problem. Deleting the file also seems to work - it's recreated with a pair of zero bytes in it.
I can confirm that this also happens with Evolution on my F-19 box. Chown fixed the issue as written in comment #2.
I've got the same issues on F-19. I xhost + local: to allow access to my X session then su - to a different user running most gnome applications produces (gthumb:10588): dconf-CRITICAL **: unable to create directory '/run/user/500/dconf': Permission denied. dconf will not work properly. user 500 owns the X session
I'm experiencing this exact same issue on a freshly installed system: [root@p7-1456c ~]# uname -a Linux p7-1456c.localdomain 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux One other possibly important item: [root@p7-1456c ~]# getenforce Disabled Detailed messages, for reference: http://pastebin.com/sZHzNrG4 (part 1 of 2) http://pastebin.com/ZcZLpJYQ (part 2 of 2) I was working in gnome and suddenly nothing responded other than the mouse. I could move the mouse but the screen was locked. I sshed into the system and killed the gnome session which dropped me back to the GUI logon. Attempting to logon I received an "oops" message and got bumped back to the GUI logon. Next reading the above information I removed /run/user/1000/dconf/user and then was allowed to logon successfully. I lost everything that was open.
This is hitting me so frequently that I am seriously considering going back to f18.
It's an issue in both 18 and 19. Look at my details, above (f18).
export XDG_RUNTIME_DIR=/run/user/1000 fixes the warning for me ... , don't know if fixes something really
[root@localhost ~]# uname -a Linux localhost.localdomain 3.12.8-300.fc20.x86_64 #1 SMP Thu Jan 16 01:07:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I'm having the same problem in F20. The system freezes, wakes up, freezes again. After rebooting the logs show: This message repeated 20 times: [about how many times the system froze] Jan 30 19:32:00 localhost.localdomain gnome-session[1608]: dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly. [Then] -- Reboot -- As I am just instaling the system, after I log in on my user account it is common that I have an su -l in a gnome-terminal and then spawn some emacs sessions from that.
for me the original problem with emacs disappeared for F20. Issuing a command like this: export XDG_RUNTIME_DIR=/run/user/$UID actually brings back the problem again. In my case there does not exist a directory /run/user/$PID/ for the alternative username that I use as mentioned above.
I just experienced this on fresh LMDE 201403 install and fixed it like so: sudo chown -R <user>.<user> /run/user/1000/dconf/ The dconf directory was owned by root.root, probably after some sudo commands. Hope this helps
This is not an emacs issue. For me it started with Fedora 21 (I did not appear to have the problem before the upgrade). This same message appears with other applications launched at the prompt, such as gedit (but not leafpad); and others if you look in the .xsession-errors file. As others elsewhere have observed, adding: export NO_AT_BRIDGE=1 to the .bashrc file causes the errors not to show, and eliminates that delay in starting the application. This does not seem like a fix, but more like addressing a symptom.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug is still there with Fedora 23 (Mate desktop) Terminal: # su # nautilus --browser & (nautilus:14494): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly. And the whole desktop functionality (wm) gets locked for a loooong while. This bug is not emacs releated. This is possibly a design problem and should be WONTFIX and meaning that users which need to use su (sysadmins etc.) should consider to drop gnome desktops. //arl ---- (Hope you one day get/construct a bug tracking system which automatically links old EOL bugs to new releases when they are still open and not fixed. So one does not end up posting to old CLOSED bugs .. which still are open with new release. Search gives only open bug Bug 896648 when used search keywords: Permission denied. dconf will not work properly. Still: please do not close bugs when EOL just move to as new release bugs. I do undestand statistics look much better when there are no open bugs but new version does not automatically fix old bugs)
feel free to reopen it
Sorry, but I do not have any permissions. (you should have guessed that). Would have done F19 -> F23 and changed status -> OPEN, priority -> medium or status -> WONTFIX --- General question: I don't now if it is better to whine in G+ or write Bugzilla bugs. Have installed Fedora 23 to HP Elitebooks 8760w and 8770w, my current work engines, and have had tremendeous problems with Wi-Fi (installation lacks proper firmware), Sound (Intel HD audio is visible but is not visible), and DVD burning (blanks will be automounted, but not visible to brasero etc.), DVD automounting (getting rid of it), etc. Seems like lots of old problems/bugs (2010/2012/even older) are popping up again. Bugzilla itself should, i.e. the end result should be before closing a test script. Do know HW dependent bugs cannot be tested but the most common ones should create unit type test script as an end result and without it bugs should not be able to be closed. //arl
(In reply to Ari Lemmke from comment #17) if you are have an fas account or something like this, you should be able to reopen this bug, is not need great permissions. I won't open it because don't know if it is a bug really . IIRC this is almost an inoffensive warning and as comment #8 states : export XDG_RUNTIME_DIR=/run/user/1000 fixes the warning for me ... https://ask.fedoraproject.org/ is a good place to start to ask
This situation makes desktop switching impossible for 5 or so minutes. Have autohide for panels and only current desktop may be used because panels won't be available (using 16 desktops). The real problem is not the printed messages. The problem is DOS situation. I think this will escalate to situation where you will end up having mate-panel sending you: Could not launch application Failed to fork (Cannot allocate memory) Even though have 0.5GB free memory and 4GB free swap. (starting programs directly using shell works, like gnome-terminal &) This escalation is really old bug too. From 2012 or earlier. mate-panel --replace fixes it but it is just a kludge and not a real fix. Do you think a normal user / person / people are able to use export XDG_RUNTIME_DIR=/run/user/1000 etc. commands / managing shell environment? (I do know that Fedora is not even intended for common people.)
See #1296778. Smells like a SELinux permission issue in F23.
Seeing this on Fedora 25: Mar 01 01:01:02 myworkstation run-parts[5606]: (/etc/cron.hourly) starting 0anacron Mar 01 01:01:02 myworkstation anacron[5615]: Anacron started on 2017-03-01 Mar 01 01:01:02 myworkstation run-parts[5617]: (/etc/cron.hourly) finished 0anacron Mar 01 01:01:03 myworkstation anacron[5615]: Normal exit (0 jobs run) Mar 01 01:10:17 myworkstation tracker-extract[1960]: unable to create file '/run/user/1202/dconf/user': Permission denied. dconf will not work properly. Mar 01 01:11:08 myworkstation tracker-store[2034]: Could not create FTS delete statement: table fts5 has no column named nco:hobby Mar 01 01:13:33 myworkstation tracker-extract[1960]: Could not insert metadata for item "file:///home/users/ts/Desktop/file.pptx": Unable to insert multiple values for subject `urn:uuid:ca3fad20-5dc8-49c1-8d26-50a8e36bd5 Mar 01 01:13:33 myworkstation tracker-extract[1960]: If the error above is recurrent for the same item/ID, consider running "tracker-extract" in the terminal with the TRACKER_VERBOSITY=3 environment variable, and filing a bug with the additional information
As per my previous comments this seems related to Tracker and especially when Tracker runs during a backup, e.g., a tar of large files like /home, and tries to index places like the Trash. I uninstalled Tracker and the messages go away.
This could be relevant to this bug: https://bugzilla.gnome.org/show_bug.cgi?id=779342
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.