“error: XDG_RUNTIME_DIR not set in the environment.” when attempting to run nautilus as root
I am attempting to run nautilus as root but when I run "sudo nautilus" from the terminal, I get the following error:
error: XDG_RUNTIME_DIR not set in the environment.
(nautilus:9341): Gtk-WARNING **: cannot open display:
The issue does not occur when I attempt to run nautilus as non-root. I am using ubuntu 14.04. Does anyone know how I can fix this?
nautilus sudo
add a comment |
I am attempting to run nautilus as root but when I run "sudo nautilus" from the terminal, I get the following error:
error: XDG_RUNTIME_DIR not set in the environment.
(nautilus:9341): Gtk-WARNING **: cannot open display:
The issue does not occur when I attempt to run nautilus as non-root. I am using ubuntu 14.04. Does anyone know how I can fix this?
nautilus sudo
Just for the record, I ended up here after I had the same error come up when trying to do X11Forwarding via ssh. Solution: I had forgotten to use the-X
option when starting my ssh session.
– JW.
May 15 '15 at 11:47
add a comment |
I am attempting to run nautilus as root but when I run "sudo nautilus" from the terminal, I get the following error:
error: XDG_RUNTIME_DIR not set in the environment.
(nautilus:9341): Gtk-WARNING **: cannot open display:
The issue does not occur when I attempt to run nautilus as non-root. I am using ubuntu 14.04. Does anyone know how I can fix this?
nautilus sudo
I am attempting to run nautilus as root but when I run "sudo nautilus" from the terminal, I get the following error:
error: XDG_RUNTIME_DIR not set in the environment.
(nautilus:9341): Gtk-WARNING **: cannot open display:
The issue does not occur when I attempt to run nautilus as non-root. I am using ubuntu 14.04. Does anyone know how I can fix this?
nautilus sudo
nautilus sudo
asked Apr 28 '14 at 1:02
quantumbutterflyquantumbutterfly
2932416
2932416
Just for the record, I ended up here after I had the same error come up when trying to do X11Forwarding via ssh. Solution: I had forgotten to use the-X
option when starting my ssh session.
– JW.
May 15 '15 at 11:47
add a comment |
Just for the record, I ended up here after I had the same error come up when trying to do X11Forwarding via ssh. Solution: I had forgotten to use the-X
option when starting my ssh session.
– JW.
May 15 '15 at 11:47
Just for the record, I ended up here after I had the same error come up when trying to do X11Forwarding via ssh. Solution: I had forgotten to use the
-X
option when starting my ssh session.– JW.
May 15 '15 at 11:47
Just for the record, I ended up here after I had the same error come up when trying to do X11Forwarding via ssh. Solution: I had forgotten to use the
-X
option when starting my ssh session.– JW.
May 15 '15 at 11:47
add a comment |
4 Answers
4
active
oldest
votes
When you run software as another user you're in fact starting the new minimal and isolated environment that doesn't carry on some "excessive" variables (among others variables responsible for injecting libraries or setting certain privileges). Replace your sudo nautilus
call with the following - it will carry on user-specific x server settings from the current session:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus
This is a one time low level solution but it will work on a malconfigured machine. If you want to permanently "fix your sudo
" you need to find the issue with your environment configuration and correct it as described in other answers.
1
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Runningsudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.
– user94959
Mar 4 '15 at 10:57
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material trypkexec
andsudo
man pages as well as google for the related dispute.
– cprn
Mar 4 '15 at 16:43
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its sayingCannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?
– user94959
Mar 5 '15 at 11:58
1
@sherrellbc I'm telling explicitly policy kit to runenv
before runningnautilus
and the former takes care for setting the variables for me. You can checkman env
.
– cprn
Aug 21 '17 at 13:54
1
@cprn D'oh. I should have checked the man page first.env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
|
show 4 more comments
To make it easy - more explained the new booting of my system.
After all explainings here -I came to the result - and "env" in terminal said already that is right for these session:
these two rows to use the environment-variable:
for the tmp behaviour I have choosen:
mkdir -pv ~/.cache/xdgr
for the environment-variable to set:
export XDG_RUNTIME_DIR=$PATH:~/.cache/xdgr
but which reaction are given by the other paths??
Than it looks so:
XDG_RUNTIME_DIR=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/usernow/.cache/xdgr
after closing the terminal and a new open for the recall of env they tells:
XDG_RUNTIME_DIR=/run/user/1001
note: it is ok for the user under ubuntu, root need more (last info by term - with 0700 permissions)
New contributor
add a comment |
I also had the same problem on Ubuntu 14.04.
Open terminal by pressing,
Ctrl + Alt+ T
then sudo visudo
change the line
Defaults env_keep="https_proxy"
to
Defaults env_keep += "https_proxy"
It worked like charm.
It works but setting same for$XAUTHORITY
defies the purpose.
– cprn
Aug 21 '17 at 13:55
add a comment |
If you are getting this error in Docker ; this is what I do
# sudo xhost +
access control disabled, clients can connect from any host
# export DISPLAY=:0.0
# docker run -it --env DISPLAY=unix$DISPLAY --privileged --volume /tmp/.X11-unix:/tmp/.X11-unix .. rest of your Docker arugments
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f456689%2ferror-xdg-runtime-dir-not-set-in-the-environment-when-attempting-to-run-naut%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
When you run software as another user you're in fact starting the new minimal and isolated environment that doesn't carry on some "excessive" variables (among others variables responsible for injecting libraries or setting certain privileges). Replace your sudo nautilus
call with the following - it will carry on user-specific x server settings from the current session:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus
This is a one time low level solution but it will work on a malconfigured machine. If you want to permanently "fix your sudo
" you need to find the issue with your environment configuration and correct it as described in other answers.
1
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Runningsudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.
– user94959
Mar 4 '15 at 10:57
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material trypkexec
andsudo
man pages as well as google for the related dispute.
– cprn
Mar 4 '15 at 16:43
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its sayingCannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?
– user94959
Mar 5 '15 at 11:58
1
@sherrellbc I'm telling explicitly policy kit to runenv
before runningnautilus
and the former takes care for setting the variables for me. You can checkman env
.
– cprn
Aug 21 '17 at 13:54
1
@cprn D'oh. I should have checked the man page first.env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
|
show 4 more comments
When you run software as another user you're in fact starting the new minimal and isolated environment that doesn't carry on some "excessive" variables (among others variables responsible for injecting libraries or setting certain privileges). Replace your sudo nautilus
call with the following - it will carry on user-specific x server settings from the current session:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus
This is a one time low level solution but it will work on a malconfigured machine. If you want to permanently "fix your sudo
" you need to find the issue with your environment configuration and correct it as described in other answers.
1
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Runningsudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.
– user94959
Mar 4 '15 at 10:57
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material trypkexec
andsudo
man pages as well as google for the related dispute.
– cprn
Mar 4 '15 at 16:43
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its sayingCannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?
– user94959
Mar 5 '15 at 11:58
1
@sherrellbc I'm telling explicitly policy kit to runenv
before runningnautilus
and the former takes care for setting the variables for me. You can checkman env
.
– cprn
Aug 21 '17 at 13:54
1
@cprn D'oh. I should have checked the man page first.env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
|
show 4 more comments
When you run software as another user you're in fact starting the new minimal and isolated environment that doesn't carry on some "excessive" variables (among others variables responsible for injecting libraries or setting certain privileges). Replace your sudo nautilus
call with the following - it will carry on user-specific x server settings from the current session:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus
This is a one time low level solution but it will work on a malconfigured machine. If you want to permanently "fix your sudo
" you need to find the issue with your environment configuration and correct it as described in other answers.
When you run software as another user you're in fact starting the new minimal and isolated environment that doesn't carry on some "excessive" variables (among others variables responsible for injecting libraries or setting certain privileges). Replace your sudo nautilus
call with the following - it will carry on user-specific x server settings from the current session:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY nautilus
This is a one time low level solution but it will work on a malconfigured machine. If you want to permanently "fix your sudo
" you need to find the issue with your environment configuration and correct it as described in other answers.
edited Sep 12 '18 at 12:06
answered May 16 '14 at 22:26
cprncprn
7391620
7391620
1
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Runningsudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.
– user94959
Mar 4 '15 at 10:57
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material trypkexec
andsudo
man pages as well as google for the related dispute.
– cprn
Mar 4 '15 at 16:43
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its sayingCannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?
– user94959
Mar 5 '15 at 11:58
1
@sherrellbc I'm telling explicitly policy kit to runenv
before runningnautilus
and the former takes care for setting the variables for me. You can checkman env
.
– cprn
Aug 21 '17 at 13:54
1
@cprn D'oh. I should have checked the man page first.env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
|
show 4 more comments
1
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Runningsudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.
– user94959
Mar 4 '15 at 10:57
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material trypkexec
andsudo
man pages as well as google for the related dispute.
– cprn
Mar 4 '15 at 16:43
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its sayingCannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?
– user94959
Mar 5 '15 at 11:58
1
@sherrellbc I'm telling explicitly policy kit to runenv
before runningnautilus
and the former takes care for setting the variables for me. You can checkman env
.
– cprn
Aug 21 '17 at 13:54
1
@cprn D'oh. I should have checked the man page first.env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
1
1
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Running
sudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.– user94959
Mar 4 '15 at 10:57
@Cyprian Guerra - This doesn't set in to the environment, this only lets you run one time. This is hardly helpful. Running
sudo nautilus
should work as normal from terminal when run. Normally whenever I do that from terminal on a fresh install it opens up as normal with sudo.– user94959
Mar 4 '15 at 10:57
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material try
pkexec
and sudo
man pages as well as google for the related dispute.– cprn
Mar 4 '15 at 16:43
@user94959 You don't understand the basic principle - the new environment is being set, the variables are carried over, the task runs, when the task exits this separate environment is being destroyed. Therefore yes, you need to set the variables for every new environment. If you wish more reading material try
pkexec
and sudo
man pages as well as google for the related dispute.– cprn
Mar 4 '15 at 16:43
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its saying
Cannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?– user94959
Mar 5 '15 at 11:58
@CyprianGuerra then how come when I try to open application from the desktop menu that requires elevated privileges can run after password input? obviously there's something missing in the configuration if it won't launch correctly because it's not set in the XDG environment like normal? the issue is when its saying
Cannot open display
means something is missing from it's configuration file because something modified it and removed it from the environment when it shouldn't of. So how can it be set back into the environment permanently then so I don't have to deal with this?– user94959
Mar 5 '15 at 11:58
1
1
@sherrellbc I'm telling explicitly policy kit to run
env
before running nautilus
and the former takes care for setting the variables for me. You can check man env
.– cprn
Aug 21 '17 at 13:54
@sherrellbc I'm telling explicitly policy kit to run
env
before running nautilus
and the former takes care for setting the variables for me. You can check man env
.– cprn
Aug 21 '17 at 13:54
1
1
@cprn D'oh. I should have checked the man page first.
env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
@cprn D'oh. I should have checked the man page first.
env COMMAND ARG ...
– sherrellbc
Aug 21 '17 at 18:29
|
show 4 more comments
To make it easy - more explained the new booting of my system.
After all explainings here -I came to the result - and "env" in terminal said already that is right for these session:
these two rows to use the environment-variable:
for the tmp behaviour I have choosen:
mkdir -pv ~/.cache/xdgr
for the environment-variable to set:
export XDG_RUNTIME_DIR=$PATH:~/.cache/xdgr
but which reaction are given by the other paths??
Than it looks so:
XDG_RUNTIME_DIR=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/usernow/.cache/xdgr
after closing the terminal and a new open for the recall of env they tells:
XDG_RUNTIME_DIR=/run/user/1001
note: it is ok for the user under ubuntu, root need more (last info by term - with 0700 permissions)
New contributor
add a comment |
To make it easy - more explained the new booting of my system.
After all explainings here -I came to the result - and "env" in terminal said already that is right for these session:
these two rows to use the environment-variable:
for the tmp behaviour I have choosen:
mkdir -pv ~/.cache/xdgr
for the environment-variable to set:
export XDG_RUNTIME_DIR=$PATH:~/.cache/xdgr
but which reaction are given by the other paths??
Than it looks so:
XDG_RUNTIME_DIR=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/usernow/.cache/xdgr
after closing the terminal and a new open for the recall of env they tells:
XDG_RUNTIME_DIR=/run/user/1001
note: it is ok for the user under ubuntu, root need more (last info by term - with 0700 permissions)
New contributor
add a comment |
To make it easy - more explained the new booting of my system.
After all explainings here -I came to the result - and "env" in terminal said already that is right for these session:
these two rows to use the environment-variable:
for the tmp behaviour I have choosen:
mkdir -pv ~/.cache/xdgr
for the environment-variable to set:
export XDG_RUNTIME_DIR=$PATH:~/.cache/xdgr
but which reaction are given by the other paths??
Than it looks so:
XDG_RUNTIME_DIR=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/usernow/.cache/xdgr
after closing the terminal and a new open for the recall of env they tells:
XDG_RUNTIME_DIR=/run/user/1001
note: it is ok for the user under ubuntu, root need more (last info by term - with 0700 permissions)
New contributor
To make it easy - more explained the new booting of my system.
After all explainings here -I came to the result - and "env" in terminal said already that is right for these session:
these two rows to use the environment-variable:
for the tmp behaviour I have choosen:
mkdir -pv ~/.cache/xdgr
for the environment-variable to set:
export XDG_RUNTIME_DIR=$PATH:~/.cache/xdgr
but which reaction are given by the other paths??
Than it looks so:
XDG_RUNTIME_DIR=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/usernow/.cache/xdgr
after closing the terminal and a new open for the recall of env they tells:
XDG_RUNTIME_DIR=/run/user/1001
note: it is ok for the user under ubuntu, root need more (last info by term - with 0700 permissions)
New contributor
edited Jan 10 at 1:21
New contributor
answered Jan 9 at 2:39
AndrewAndrew
113
113
New contributor
New contributor
add a comment |
add a comment |
I also had the same problem on Ubuntu 14.04.
Open terminal by pressing,
Ctrl + Alt+ T
then sudo visudo
change the line
Defaults env_keep="https_proxy"
to
Defaults env_keep += "https_proxy"
It worked like charm.
It works but setting same for$XAUTHORITY
defies the purpose.
– cprn
Aug 21 '17 at 13:55
add a comment |
I also had the same problem on Ubuntu 14.04.
Open terminal by pressing,
Ctrl + Alt+ T
then sudo visudo
change the line
Defaults env_keep="https_proxy"
to
Defaults env_keep += "https_proxy"
It worked like charm.
It works but setting same for$XAUTHORITY
defies the purpose.
– cprn
Aug 21 '17 at 13:55
add a comment |
I also had the same problem on Ubuntu 14.04.
Open terminal by pressing,
Ctrl + Alt+ T
then sudo visudo
change the line
Defaults env_keep="https_proxy"
to
Defaults env_keep += "https_proxy"
It worked like charm.
I also had the same problem on Ubuntu 14.04.
Open terminal by pressing,
Ctrl + Alt+ T
then sudo visudo
change the line
Defaults env_keep="https_proxy"
to
Defaults env_keep += "https_proxy"
It worked like charm.
edited Jul 13 '18 at 6:50
answered Aug 1 '16 at 12:12
Om PrakashOm Prakash
121117
121117
It works but setting same for$XAUTHORITY
defies the purpose.
– cprn
Aug 21 '17 at 13:55
add a comment |
It works but setting same for$XAUTHORITY
defies the purpose.
– cprn
Aug 21 '17 at 13:55
It works but setting same for
$XAUTHORITY
defies the purpose.– cprn
Aug 21 '17 at 13:55
It works but setting same for
$XAUTHORITY
defies the purpose.– cprn
Aug 21 '17 at 13:55
add a comment |
If you are getting this error in Docker ; this is what I do
# sudo xhost +
access control disabled, clients can connect from any host
# export DISPLAY=:0.0
# docker run -it --env DISPLAY=unix$DISPLAY --privileged --volume /tmp/.X11-unix:/tmp/.X11-unix .. rest of your Docker arugments
add a comment |
If you are getting this error in Docker ; this is what I do
# sudo xhost +
access control disabled, clients can connect from any host
# export DISPLAY=:0.0
# docker run -it --env DISPLAY=unix$DISPLAY --privileged --volume /tmp/.X11-unix:/tmp/.X11-unix .. rest of your Docker arugments
add a comment |
If you are getting this error in Docker ; this is what I do
# sudo xhost +
access control disabled, clients can connect from any host
# export DISPLAY=:0.0
# docker run -it --env DISPLAY=unix$DISPLAY --privileged --volume /tmp/.X11-unix:/tmp/.X11-unix .. rest of your Docker arugments
If you are getting this error in Docker ; this is what I do
# sudo xhost +
access control disabled, clients can connect from any host
# export DISPLAY=:0.0
# docker run -it --env DISPLAY=unix$DISPLAY --privileged --volume /tmp/.X11-unix:/tmp/.X11-unix .. rest of your Docker arugments
answered Jan 10 at 6:28
Alex PunnenAlex Punnen
1113
1113
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f456689%2ferror-xdg-runtime-dir-not-set-in-the-environment-when-attempting-to-run-naut%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Just for the record, I ended up here after I had the same error come up when trying to do X11Forwarding via ssh. Solution: I had forgotten to use the
-X
option when starting my ssh session.– JW.
May 15 '15 at 11:47