Tag Info

New answers tagged

4

All groups are active at all times. You can access any file that any of your groups can access. But when you create a new file/process it is created using your primary group, unless setgid or ACL defaults are in use.


1

Q1: So the question is what is the fundamental reason on why the designers chose to have this concept of a single active group even though allowing the user to have more than one supplementary groups? The original primary purpose of groups in Unix was to allow for sharing of access to files on disks. Within this use case you'd typically be accessing ...


3

One reason: when one creates a file, it can be only in one group, and this group is not specified during the file creation. So, there must be a notion of single active group.


1

the ownership is preserved, but probably you dont have the same users in both enviroments. check the user id of by example user www-data in both servers and compare it. you may see another name, but the id will be the same


1

rsync can't preserve ownership if it's being run by a non-root user on the destination system, because only the superuser is allowed to create files that are owned by someone else. Instead of using rsync create a tar file on the intermediate system. Then when you restore it on the ultimate target system, you can do so as root in order to give the original ...


1

There are a couple of ways, usermod is a good tool that comes to mind (I have trouble with it at times). Another is chfn this will generally give you a lot of options to change (phone number, office location, and other stuff). # chfn username should open your favorite editor for you to change things with. There are some unsafe methods, but I don't ...


5

sudo usermod -c "Jecht Tyre" jecht You can change it with -c option. -c is for adding comment usermod -c "YOUR NAME" username


1

You can use awk to filter out new users from /var/log/secure as follows:- awk '/new\ user/ {gsub(/,|name=/,"",$8); print $1, $2, $3, $8}' /var/log/secure Note: Debian systems (I believe) use /var/log/auth.log instead.


0

I use gksu: gksu -u myotheruser /opt/netbeans/7.3/bin/netbeans Maybe try also kdesu.


1

The passwords are stored in the shadow file, not in /etc/passwd, so you need to delete the contents of the second column from /etc/shadow. An entry should look something like this: root::16229:0:99999:7:::


1

So as you said yourself @krzysto, the solution is to add the following to the sudoers file beans ALL = (root,apache) NOPASSWD: /usr/bin/ksh -c /opt/renovations/var/script-*.sh beans ALL = (root,apache) NOPASSWD: /usr/bin/bash -c /opt/renovations/var/script-*.sh The next piece that is missing is to make sure that the group has execute permissions on the ...


0

While this is possible, it is very rarely the right way to do something. I strongly suspect that you are at best making your life overly complicated and at worst doing something unsafe when you could do the safe thing at no extra cost. SSH lets clients authenticate with a key instead of a password. This is especially useful for automated use: create a key ...


2

Just backup the /etc/shadow file, and change the users passwords with passwd: Backup the shadow file: sudo cp /etc/shadow /etc/shadow.bak Change the password of the user you want to access (e.g. testuser): sudo passwd testuser When done, restore the /etc/shadow file from the backup: sudo mv /etc/shadow.bak /etc/shadow Note that all passwords should ...


1

The reason for EPERM (the permission denied error ) is here: drwxr-xr-x 5 www-data www-data 4096 juil. 30 13:47 . The directory where you are trying to create a file (in other words change contents of the directory-file) is writeable only for user www-data, which you are not. Either mark the directory as writeable for the group, change the user to ...



Top 50 recent answers are included