Solved Adding a user to group and make groups command reflect changes without reboot?

Solved issue
I added a non sudo account to the sudo line in the /etc/group file then opened up a terminal and logged into the root account (su root) then with the same terminal logged back into the non sudo account with the su command and it was able to function as a sudo. However, if I opened another terminal the changes did not reflect and the non sudo account did not have sudo rights. Not entirely related to your post but it was an interesting find.
 


I just tried it, when I add my user to a group I don't see it active yet but when I start an ssh session to localhost I then see the group.
Thanks for testing, so it doesn't work for graphical session.

A reboot shouldn't be needed a logoff/login from the session at most.
Yes, it shouldn't be required, strange.

However, if I opened another terminal the changes did not reflect and the non sudo account did not have sudo rights.
Sounds like similar behavior to:
newgrp <group_name>

But it works only temporary.

The hack with editing /etc/group can only be exploited within terminal, but not for graphical session, not really sure why since logout/login restarts graphical.target.
Tried restarting display manager as well after logout, still not working.
 
Thanks for testing, so it doesn't work for graphical session.


Yes, it shouldn't be required, strange.


Sounds like similar behavior to:


But it works only temporary.

The hack with editing /etc/group can only be exploited within terminal, but not for graphical session, not really sure why since logout/login restarts graphical.target.
Tried restarting display manager as well after logout, still not working.
I'm on Debian 13 as well. The changes I made to the /etc/group did not take effect either after I logged out and logged back in.
 
Actually I take that last post back. I looked in my /etc/group file and noticed it reverted back to the original settings for some reason. So I added the non sudo account under the sudo line and the changes to took effect after a log in and log out. Tried this several times and the changes took effect each time.
 
I looked in my /etc/group file and noticed it reverted back to the original settings for some reason.
Edits done to /etc/group are not lost or reverted here after logout/login.
Didn't test for sudo group since I'm already sudo.

So I added the non sudo account under the sudo line and the changes to took effect after a log in and log out.
With group command output? can't reproduce.
 
Edits done to /etc/group are not lost or reverted here after logout/login.
Didn't test for sudo group since I'm already sudo.


With group command output? can't reproduce.
No I directly edited the file using:
Code:
sudo nvim /etc/group

I'm thinking the group your editing might require a restart.

Try the below:
"With recent systemd versions, the service manager is no longer stopped immediately after last session close – in default configuration there is a 10 second idle timer before that happens. Logging in too fast might cause the old manager process to continue running for the new session."

"Confirmed! Logging out and immediately back in does not add me to the group, but waiting about 15 seconds does. Thank you! "

"Thanks! I was having the issue of getting a new group membership even after switching to multi-user.target (or even rescue.target); A systemctl restart [email protected] did the trick (replace 1000 with your uid)"

From:
 
Try the below
This works, nice find!
Waiting 10 seconds after logout to log back in.

However a quicker method with sudo systemctl restart user@$(id -un).service won't work, it blocks on black screen and then need to switch to virtual terminal to restart display manager to get back, this can take more than 10 seconds so not viable.

This is now solved, thanks! @MzQ1NjExN2
 
This works, nice find!
Waiting 10 seconds after logout to log back in.

However a quicker method with sudo systemctl restart user@$(id -un).service won't work, it blocks on black screen and then need to switch to virtual terminal to restart display manager to get back, this can take more than 10 seconds so not viable.

This is now solved, thanks! @MzQ1NjExN2
No problem. I learned like five new things from this thread. :O)
 


Follow Linux.org

Members online

No members online now.

Top