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.
Related
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.
When I run 'composer update' I get this error:
Writing lock file
Generating autoload files
[ErrorException]
chmod(): Operation not permitted
*It works just fine with sudo, but then I have to reset the owner & permissions, Which is really annoying...
**I also tried to reset the owner of ~/.composer to www-data with 777, no effect.
***I'm using Ubuntu 16.04 LTS + Apache/2.4.18 & php7.0.26
Any idea?
chmod will only work without sudo if the owner of the file is the same as the one running the composer update command.
The problem is that the error message doesn't tell you which file it's trying to chmod.
This depends on the project.
Running the command in verbose mode will give you more details:
composer update -v
In my case, it gave me a stack trace, showing which file called chmod(), and the line number.
However, it didn't give me the path of the file passed to chmod().
I had to add a simple echo right before the call to chmod() (without forgetting to remove it afterwards).
Once you know which file/folder is responsible for the error message, change its owner with chown.
In my case (Magento 2.3), the culprit was the bin/magento file, which needs to be owned by the user running the composer commands.
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.
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.