I try to execute the following line on ubuntu-server 14.04:
$ sudo gedit /usr/local/svn/passwd-team
and I get this error:
error: XDG_RUNTIME_DIR not set in the environment.
(gedit: 11805): Gtk-WARNING **: can not open display:
I Googled for help and saw that I had to write:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit
Then I got the following message:
=== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authenticating is needed to run '/usr/bin/env' as the super user
Authenticating as: student,,, (student)
Password:
no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory
=== AUTHENTICATING COMPLETE ===
error: XDG_RUNTIME_DIR not set in the environment.
7
(gedit: 11807): Gtk-WARNING **: can not open display:
Now what? I just want to edit passwd-team file. please guide me.
Thanks a lot,
Orian.
Edit:
I used nano to edit that file, but the error is still there.
I have faced similar issues when using gedit after i ssh into any other user.This may be due to missing permission.
Try the following :-
Open a new terminal from your current user.
type in
sudo -i
This prompts for root password. Enter that and then you will be in able to access using root privilege.
Then Try Gedit the file you want to edit. If you need to do it using su for other user then after the above step, do
su <username>
Now Try gedit any file. Works for me.
Run the following command:
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit /usr/local/svn/passwd-team
Enter your user account password in the password field.
Explanation:
When you run gedit as another user (in this case root) 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). The command above causes to carry on user-specific X-server settings from the current session.
References:
https://askubuntu.com/a/467994/185132
I had the same problem. In my case I ran command below:
sudo visudo
In the file that opens I deleted the last line (env=http...) and I saved the file.
Then everything worked as usual.
Your explanation shows that you did not run the command with root privileges as the message appeared "Authenticating is needed to run '/usr/bin/env' as the super user"
Try to run it as
sudo pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit
Then the screen asks for root password, type your password and you should be fine.
Related
I am trying to use the SSHOperator to SSH into a remote machine and run an external application through the command line. I have setup the SSH connection via the admin page.
This section of code is used to define the commands and the SSH connection to the external machine.
sshHook = SSHHook(ssh_conn_id='remote_comp')
command_1 ="""
cd /files/232-065/Rans
bash run.sh
"""
Where 'run.sh' runs the shell script:
#!/bin/sh
starccm+ -batch run_export.java Rans_Model.sim
Which simply runs the commercial software starccm+ with some options I have specified.
This section defines the task:
inlet_profile = SSHOperator(
task_id='inlet_profile',
ssh_hook=sshHook,
command=command_1
)
I have confirmed the SSH connection works by giving a simple 'ls' command and checking the output.
The error that I get is:
bash run.sh, error: run.sh: line 2: starccm+: command not found
The command in 'run.sh' works when I am logged into the machine (it does not require a GUI). This makes me think that there is a problem with the SSH session and it is not the same as the one that Apache Airflow logs into, but I am not sure how to solve this problem.
Does anyone have any experience with this?
There is no issue with SSH connection (at least from the error message). However, the issue is with starccm+ installation path.
Please check the installation path of starccm+ .
Check if the installation path is part of $PATH env variable
$ echo $PATH
If not, then install it in the standard locations like /bin or /usr/bin etc (provided they are included in $PATH variable), or export the installed director into PATH variable like this,
$ export PATH=$PATH:/<absolute_path>
It is not ideal but if you struggle with setting the path variable you can run starccm stating the full path like:
/directory/where/star/is/installed/starccm+ -batch run_export.java Rans_Model.sim
So I'm running into this error every time I run a command in terminal (using Visual Code Studio) while doing anything within a git repository.
Terminal Git Error Message
I did some digging and found out the owner of the .config file is "root" and not me "username" (see second screenshot)Root is owner of .config file
Do you know how to change the ownership to me so I stop getting this warning message? I ran a command I found on here "sudo chown -R $(username) .config" but it wasn't recognized, then asked me for a password and wouldn't let me type anything so I closed out of terminal.
I'm new to all this and coming from a construction background and going back to school so layman's terms would be appreciated.
Thanks in advance!
sudo chown $USER path/to/.config
is the correct command. sudo asks for your password (the same one you use to login to the $USER account); for security reasons the password isn't echoed, you just have to input it blindly and press Enter.
I have a remote headless server (MacOS BigSur 11.3.1). When I log in via ssh (with either the root user or regular user), I am unable to save to the crontab.
When I use the following command:
% crontab -e
I can see a cronjob that I saved when I was logged in locally (not via ssh). After editing and exiting the crontab, I get the following error:
crontab: installing new crontab
crontab: tmp/tmp.1028: Operation not permitted
crontab: edits left in /tmp/crontab.kKYx3tt4c1
While logged into ssh, I have instead tried to edit the crontab with this command:
% sudo crontab -e
To my surprise, the cronjob that I saved when logged in locally is not listed. It is as if it is a different crontab for a different user. In any case, I can't save to the crontab when using sudo either. It gives the exact same error as above.
I have followed the advice of a few internet posts suggesting allowing the cron and sshd executables "Full Disk Access" through the Mac System Preferences. However, the same error persists.
I'm not sure what to try next.
So the issue was solved by giving sshd-keygen-wrapper full disk access. Don't ask me why that needs it, but it is working now. I hope this helps anyone with the same issue.
I am pretty new at php and ubuntu. I have 2 servers set up, one for development and one for staging. On the dev machine I can use the at command without a problem, but on staging I get a permissions error. The at.deny (and at.allow) files are identical, so it must be another permissions issue.
Any clues?
I see that on the staging server I can only use at command as root. How can I fix this to be able to use the at command as www-data? Again... I checked the at.allow and at.deny files ... they are not the problem here.
1) Check if you have file /etc/at.allow.
If it exists - just add your user in new line.
If not exists - try to find your user in /etc/at.deny and remove/comment it.
2) Restart "at" daemon:
sudo atd restart
3) Check:
at -l
or
sudo -u myuser at -l
The error should not be output.
When using the db2setup (Wizard) to install a new version of DB2 V10.5.0.3 (or the universal fixpack V10.5.7) the installer appears to hang near the end of the Create DB2 Administration task. There is a das directory created in the /home/dasusrX directory but it has no visible files. The logs show no errors. Manually trying to create the DAS also hangs using dascrt -u dasusrX
In the console where I launched the db2setup I found I needed to enter the dasusrX password a couple of times. There is no prompt displayed. I believe the system also hangs during the Configuring DB2 instances task and luckily I used the same password for other users so I entered it there as well to complete the install.
I figured this out running the dascrt -d -u dasusrX and saw it hung at the su dasusrX -c /bin/pwd command and when I tried that command manually, it propmted for the dasusrX password. This may be a unique situation for our server set up as root is accessible only via sudo -i so perhaps in other situations there would be no prompt for dasusrX password when using su as root.