Fbi is a framebuffer image viewer that does not need an X-server setup. It's perfect for what I want to achieve: a stand alone dedicated slide show.
I want to run the following command as a non-root user:
fbi -d /dev/fb0 -T 1 foo.jpg
When I run fbi as non-root, the result on tty1 is:
access /dev/tty1: Permission denied
I can perfectly run the command as root (sudo ...), but that's not desirable. My question is: how can I run fbi as non-root user on a tty?
The setup of the rpi4 is "headless": no X-server installed, the fbi command is issued from ssh or crontab, the output tty1 is a screen connected to a HDMI port on the rpi4.
I tried many things:
checked all possible forums, many of which address this problem without giving a satisfactory solution. The man page for fbi suggests adding the user to the vido and tty groups which I did but to no avail.
added the user to the groups tty and video
changed permissions on tty1 and fb0 to 666. Interestingly the error message changes to ...
ioctl VT_ACTIVATE: Operation not permitted.
Of course, after reboot the permissions of the /dev/tty1 and /dev/fb0 change back to normal. So changing these permissions is no good idea at all, even if it would work, which it doesn't.
Thanks you guys for your help!
I'm running bullseye on a rpi3.
Here is how I got it to work (from inside a docker container fwiw):
[x] add the user to the tty and video groups
[x] change permission on /dev/tty1 to allow group read
[ ] grant capability CAP_SYS_TTY_CONFIG to the fbi binary
The last part is what you missed (the cap).
One liner to get it:
setcap 'cap_sys_tty_config+ep' $(which fbi)
[UPDATED]
Also, to persist the permission on the tty on raspbian, look into
cat /usr/lib/udev/rules.d/50-udev-default.rules | grep "\"tty\[0"
Problem
I am confused about rsync daemon and permissions. Unfortunately I cannot figure out why I get
rsync: opendir "/." (in share) failed: Permission denied (13) and
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [generator=3.1.2].
Obviously, by searching the web and looking into the manpage of rsync / rsyncd.conf I was not able to solve this issue.
Setup
Here is my /etc/rsyncd.conf owned by root with 644 permissions:
log file = /var/log/rsyncd.log
[share]
comment = data
path = /path/to/data
uid = root
gid = root
read only = false
auth users = syncuser
secrets file = /etc/rsyncd.secrets
Note, /path/to/data is owned by root with 755 permissions (though random user or syncuser is also not working).
Besides, /etc/rsyncd.secrets has 600 permissions and is owned by root (I also tried 400 though same issue)
syncuser:passwd
To start the service (on CentOS7)
sudo systemctl start rsyncd
A first test as a random user on the host machine running the daemon, (also running with sudo or as syncuser has no effect)
rsync user#host::
returns share data showing that the configuration is fine?!
However
rsync user#host::share
leads to the errors mentioned above.
Tries
Playing with chmod (777) and chown (root:root, random user:user, syncuser:syncuser) of /path/to/data was not changing anything. Moreover I varied uid and gid to nobody but also without success.
Running above rsync command on an actual client, from which I want to ultimately copy data to the host is of course also failing.
So what am I missing here? Any hints are of course highly appreciated.
could you check SELinux?
If it is enforced, the directory /path/to/data need to be labeled correctly.
For example,
chcon -R -t public_content_t /path/to/data
I have 20 machines where I need to create a user and set his password. I can create the accounts and set the passwords using a for loop. The inside of the for loop is given as follows
ssh -t user1#$node_name 'sudo useradd user2'
ssh -t user1#$node_name 'sudo passwd user2'
However, this requires me to input the password for user1 first and then input the new password for user2. I tried it for 2 machines and it works. I however do not like the wasteful effort involved and am guessing there would me a more efficient way of doing so. Any ideas?
To remove the need to enter user1's password, you can mess with the sudo -A or -a options on $node_name to get authentication to happen automatically in some other way.
To remove the need to type user2's password, you can try something like this:
ssh -t user1#$node_name "sudo echo $newpass | useradd user2 --stdin"
I have a file that is locked/checked out exclusively by a user who is no longer with the company. I need to make changes and want to know how to "steal the lock".
Ask your perforce admin to remove the lock by issuing
p4 unlock -f <file>
PS: To reuse the departed user's license, your perforce admin might also want clean up the files left opened by him. He can revert the pending edits if they are useless or transfer them to another user via "p4 reopen".
The "reopen" and "revert after reopen" can also be performed by ordinary users.
"Locked" and "checked out" are two different things which require two different operations to undo. As Peter G. said, an admin can unlock a file with the unlock command:
p4 unlock -f <file>
However, to revert a file checked out by another user, you need to impersonate that user by passing their client (workspace name), host (computer name) and user names to the revert command, like so:
p4 -c theirclient -H theirhost -u theiruser revert filename
So if a Perforce user named jdoe has file foo.txt checked out in workspace ws1 on a host named joesPC, an admin can revert it with the following command:
p4 -c ws1 -H joesPC -u jdoe revert foo.txt
You have three choices, and if you don't know the user's password all three will require an admin.
p4 unlock -f filename
this will only work if you are an admin. Also, it will not work on files with a +l filetype, such as binary+l—in such a scenario it will need to be reverted.
With the user's password (get a p4 admin to clear it out if no one knows what it is), use a command like the one raven suggested:
p4 -c theirclient -H theirhost -u theiruser -p theirpassword revert -k filename
Or without the password, get an admin to use this sequence:
$ p4 login theiruser
User theiruser logged in.
$ p4 -c theirclient -H theirhost revert -k filename
Some dummy users may checkout the entire depot and lock all the files:
If you have admin access then you can use:
p4 client -d -f clientname
Where clientname is the name of the workspace.
I had similar issue on a file on my client. I was saying can't edit file, because opened on the same client. Wasted couple days waiting admin to unlock, but below worked for me:
p4 opened -x
p4 -c <client_name> unlock -x //filepath
I'm working to set up Panda on an Amazon EC2 instance.
I set up my account and tools last night and had no problem using SSH to interact with my own personal instance, but right now I'm not being allowed permission into Panda's EC2 instance.
Getting Started with Panda
I'm getting the following error:
# WARNING: UNPROTECTED PRIVATE KEY FILE! #
Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
I've chmoded my keypair to 600 in order to get into my personal instance last night, and experimented at length setting the permissions to 0 and even generating new key strings, but nothing seems to be working.
Any help at all would be a great help!
Hm, it seems as though unless permissions are set to 777 on the directory, the ec2-run-instances script is unable to find my keyfiles.
I've chmoded my keypair to 600 in order to get into my personal instance last night,
And this is the way it is supposed to be.
From the EC2 documentation we have "If you're using OpenSSH (or any reasonably paranoid SSH client) then you'll probably need to set the permissions of this file so that it's only readable by you." The Panda documentation you link to links to Amazon's documentation but really doesn't convey how important it all is.
The idea is that the key pair files are like passwords and need to be protected. So, the ssh client you are using requires that those files be secured and that only your account can read them.
Setting the directory to 700 really should be enough, but 777 is not going to hurt as long as the files are 600.
Any problems you are having are client side, so be sure to include local OS information with any follow up questions!
Make sure that the directory containing the private key files is set to 700
chmod 700 ~/.ec2
To fix this,
you’ll need to reset the permissions back to default:
sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 600 ~/.ssh/id_rsa.pub
If you are getting another error:
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/geek/.ssh/known_hosts).
This means that the permissions on that file are also set incorrectly, and can be adjusted with this:
sudo chmod 644 ~/.ssh/known_hosts
Finally, you may need to adjust the directory permissions as well:
sudo chmod 755 ~/.ssh
This should get you back up and running.
I also got the same issue, but I fix it by changing my key file permission to 600.
sudo chmod 600 /path/to/my/key.pem
The private key file should be protected. In my case i have been using the public_key authentication for a long time and i used to set the permission as 600 (rw- --- ---) for private key and 644 (rw- r-- r--) and for the .ssh folder in the home folder you will have 700 permission (rwx --- ---). For setting this go to the user's home folder and run the following command
Set the 700 permission for .ssh folder
chmod 700 .ssh
Set the 600 permission for private key file
chmod 600 .ssh/id_rsa
Set 644 permission for public key file
chmod 644 .ssh/id_rsa.pub
Change the File Permission using chmod command
sudo chmod 700 keyfile.pem
On windows, Try using git bash and use your Linux commands there. Easy approach
chmod 400 *****.pem
ssh -i "******.pem" ubuntu#ec2-11-111-111-111.us-east-2.compute.amazonaws.com
Keep your private key, public key, known_hosts in same directory and try login as below:
ssh -I(small i) "hi.pem" ec2-user#ec2-**-***-**-***.us-west-2.compute.amazonaws.com
Same directory in the sense,
cd /Users/prince/Desktop.
Now type ls command
and you should see
**.pem **.ppk known_hosts
Note: You have to try to login from the same directory or you'll get a permission denied error as it can't find the .pem file from your present directory.
If you want to be able to SSH from any directory, you can add the following to you ~/.ssh/config file...
Host your.server
HostName ec2-user#ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes
Now you can SSH to your server regardless of where the directory is by simply typing ssh your.server (or whatever name you place after "Host").
Just to brief the issue, that pem files permissions are open for every user on machine i.e any one can read and write on that file
On windows it difficult to do chmod the way I found was using a git bash.
I have followed below steps
Remove user permissions
chmod ugo-rwx abc.pem
Add permission only for that user
chmod u+rw
run chmod 400
chmod 400 abc.pem
4.Now try ssh -i for your instance
If you are on a windows machine just copy the .pem file into C drive any folder and
re-run the command.
ssh -i /path/to/keyfile.pem user#some-host
In my case, I put that file in downloads and this actually works.
Or follow this https://99robots.com/how-to-fix-permission-error-ssh-amazon-ec2-instance/
I am thinking about something else, if you are trying to login with a different username that doesn't exist this is the message you will get.
So I assume you may be trying to ssh with ec2-user but I recall recently most of centos AMIs for example are using centos user instead of ec2-user
so if you are
ssh -i file.pem centos#public_IP please tell me you aretrying to ssh with the right user name otherwise this may be a strong reason of you see such error message even with the right permissions on your ~/.ssh/id_rsa or file.pem
The solution is to make it readable only by the owner of the file, i.e. the last two digits of the octal mode representation should be zero (e.g. mode 0400).
OpenSSH checks this in authfile.c, in a function named sshkey_perm_ok:
/*
* if a key owned by the user is accessed, then we check the
* permissions of the file. if the key owned by a different user,
* then we don't care.
*/
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
error("###########################################################");
error("# WARNING: UNPROTECTED PRIVATE KEY FILE! #");
error("###########################################################");
error("Permissions 0%3.3o for '%s' are too open.",
(u_int)st.st_mode & 0777, filename);
error("It is required that your private key files are NOT accessible by others.");
error("This private key will be ignored.");
return SSH_ERR_KEY_BAD_PERMISSIONS;
}
See the first line after the comment: it does a "bitwise and" against the mode of the file, selecting all bits in the last two octal digits (since 07 is octal for 0b111, where each bit stands for r/w/x, respectively).
sudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 600 ~/.ssh/id_rsa.pub
The above 3 commands should solve the problem!
Just a note for anyone who stumbles upon this:
If you are trying to SSH with a key that has been shared with you, for example:
ssh -i /path/to/keyfile.pem user#some-host
Where keyfile.pem is the private/public key shared with you and you're using it to connect, make sure you save it into ~/.ssh/ and chmod 777.
Trying to use the file when it was saved elsewhere on my machine was giving the OP's error. Not sure if it is directly related.