When assigning a user's secondary group list using:

# usermod -G <grouplist> <user>

is it possible to force this group assignment to take effect without logging out all running sessions?

This would be very useful in the situation where a Screen session exists with many running shells, as the entire session essentially needs to be destroyed to make the group assignment take effect.

I think I can change the user's primary group in a running shell using the newgrp command - is there some alternative that would work for secondary groups?

Ideally, I'd want something that would take effect in each shell without being run manually in every one, but failing that, maybe some way of forcing Screen to execute the same command in each.

  • I know that at least for some window / session managers it's possible to do this such that the session picks up the new group and it's available to any new processes started from the menus, panel buttons or whatever. I came here just now looking to find that again, so can't say just now how to do it, and it's probably specific to the window manager.
    – mc0e
    Commented Nov 9, 2015 at 14:27

16 Answers 16


Horribly hacky, but you could use two layers of newgrp to achieve this for a particular group:

id -g

...will give you the current primary group ID. We'll call this orig_group for the purposes of this example. Then:

newgrp <new_group_name>

...will switch you to that group as the primary and add it to the list of groups returned by groups or id -G. Now, a further:

newgrp <orig_group_name>

...will get you a shell in which you can see the new group and the primary is the original one.

This is horrible and will only get you one group added at a time, but it has helped me out a couple of times to get groups added without logging out/in my whole X session (e.g. to get fuse added as a group to a user so that sshfs will work).


  • This doesn't require you to type your password either, which su will

  • Each call to newgrp launches a new shell (as a child of the current shell)

  • The current shell can be "replaced" with the exec command

    exec newgrp <new_group_name>
  • Using exec will resolve the caching issue for the current branch of the pstree

    I.e. if you are logged in to a window manager, every new terminal you launch will be a child of an earlier branch than the one "corrected" by this exercise and will therefore inherit the cached gid map.

  • 3
    On Fedora I had to do newgrp $USER instead of newgrp <orig_group>. That means I didn't have to find my original primary group ID, so it's even easier than this solution. Commented Jan 3, 2014 at 17:08
  • 4
    I found it was sufficient to do newgrp <new group name>. This was Ubuntu 14.04 Commented Mar 18, 2016 at 21:42
  • 9
    @EdwardFalk right, but you don't (might not) want to leave that group as your primary...
    – mimoralea
    Commented May 26, 2016 at 22:08
  • 7
    Note that each newgrp creates a new shell, so when you need to fully exit from your session you need to do "exit exit exit" to get all the way out (:
    – jwd
    Commented Jan 4, 2017 at 17:45
  • 11
    @jwd You can avoid exit; exit; exit you could use exec to replace the current shell like exec newgrp new_group, then exec newgrp orig_group.
    – Tacahiroy
    Commented Sep 6, 2019 at 6:41

From inside a shell, you can issue the following command

su - $USER

id will now list the new group:

  • 6
    I think this the best approach in many cases, but the original poster did want to update multiple shells within a screen session. This solution would have be be done from each shell. Commented Dec 13, 2011 at 8:57
  • 4
    The original solution would also only fix a single shell session in screen. I just tested that. The reason this solution works is because you are spawning a complete new session rather than inheriting from the original environment.
    – Dror
    Commented Feb 6, 2014 at 5:24
  • 2
    You can make the command slightly more generic like so: su - $USER
    – bmaupin
    Commented Mar 26, 2015 at 22:32
  • 2
    This requires you to type a password though, which might be awkward/unwanted if you are trying to do it in lots of sessions.
    – Legooolas
    Commented Apr 15, 2016 at 13:20
  • 2
    Note that you won't be able to run X applications without doing export DISPLAY=:0.0 after su - $USER. (Or replace ":0.0" with whatever echo $DISPLAY outputs.)
    – nijoakim
    Commented Dec 19, 2019 at 13:07

This nifty trick from this link works great!

exec su -l $USER

I figured I'd post it here as every time I forget how to do this, this is the first link that come up in google.

  • 33
    +1 for not putting the user in a subshell; you can logout/exit as usual with this. Also, if NOPASSWD: is set in /etc/sudoers, you can instead use exec sudo su -l $USER to avoid being prompted for password.
    – Ivan X
    Commented Aug 9, 2014 at 15:06
  • 35
    Be advised: you'll be asked for a sudo password. If you get it wrong, your terminal will close. Commented Feb 26, 2015 at 18:57
  • 1
    This only works for an interactive shell, If you try to put it in a bash.sh script as soon as this command is run the script will stop. On this related question, unix.stackexchange.com/questions/18897/…, Gilles points out that this is just the way Linux processes work. Ansible will let you refresh group but it only works for ssh connections not localhost stackoverflow.com/questions/26677064/… For localhost I've worked around it by using EC2's Userdata to pre-add the group before my first login.
    – neoakris
    Commented Dec 30, 2019 at 4:15
  • Two notes: (1) After running this I could not open X applications in this shell [Archlinux, Surface Book 2]. (2) This only works for the current shell. Else it is a good solution.
    – errolflynn
    Commented May 4, 2020 at 20:55
  • -1 since practically it switches into a different shel! - any custom env-vars eg. PATH for your venvs, XDISPLAY, SSH_CONNECTION, git-prompts, command-colors etc are all lost afterwards.
    – ankostis
    Commented Dec 23, 2022 at 11:58
  1. Getting a shell with the new group without logging out and in again

    If you're only adding one group, I used the following:

    exec sg <new_group_name> "newgrp `id -gn`"

    This is a variation on Legooolas's two-layer newgrp trick, but it is in one line and doesn't require you to manually enter your primary group.

    sg is newgrp but accepting a command to execute with the new group ID. The exec means that the new shell replaces the existing shell, so you don't need to "logout" twice.

    Unlike using su, you don't need to type in your password. It also doesn't refresh your environment (other than adding the group), so you retain your current working directory etc.

  2. Executing the command in all Screen windows in a session

    The at command in Screen runs a command in whatever windows you specify (note this is a Screen command, not a shell command).

    You can use the following command to send the command to all an existing Screen sessions:

    screen -S <session_name> -X at \# stuff 'exec sg <new_group_name> "newgrp `id -gn`"^M'

    Note the use of single quotes to preserve the backticks and get id to run in the Screen session, and the ^M to get Screen to hit 'enter' at the end of your command.

    Note also that screen's stuff command simply types the command text on your behalf. Therefore something strange may happen if one of the screen windows has a half-written command at a command prompt or is running an application other than a shell (e.g. emacs, top). If this is an issue, I have some ideas:

    • To get rid of any half-written command, you can add "^C" to the start of the command.
    • To avoid running the command in an emacs window, etc, you could ask at to filter on window title etc (in the example above, I use "#", which matches all windows, but you can filter by window title, user, etc).

    To run the command in a specific window (identified by window number), use the following:

    screen -S <session_name> -p 0 -X stuff 'exec sg <new_group_name> "newgrp `id -gn`"^M'
  • 4
    Really nice answer. Small correction: sg expects the command to be a single argument, and ignores further arguments (try sg some_group echo test). So sg new_group_name newgrp `id -gn` is actually equivalent to sg new_group_name newgrp. The reason it seems to work is that when newgrp is invoked with no arguments it uses the default group in /etc/passwd, which usually matches the current group. The fix is to quote the command: sg new_group_name "newgrp `id -gn`"
    – tom
    Commented Mar 17, 2020 at 6:21
  • 1
    @tom: if newgrp without arguments uses the default group, why bother with newgrp $(id -gn) at all? sg new_group_name newgrp is all that is needed, correct?
    – MestreLion
    Commented Jun 5, 2022 at 8:13
  • 1
    @MestreLion: The reason for id -gn is to preserve the user's current group ID in the case where the current group it is not the default group. In most cases the user's current group will be their default group, and in that case sg <new_group_name> newgrp would be fine.
    – tom
    Commented Jun 6, 2022 at 9:12
  • 1
    @tom: wow, so that snippet "loads" a new group and then is careful enough to "revert" to the user's previously current group? Sweet! Wish I could upvote more. Suggestion: replace backticks with $(), far easier to read and also standard on most (all?) shells
    – MestreLion
    Commented Jun 6, 2022 at 18:26
  • 1
    @MestreLion: Yes (like the double-newgrp trick from Legooolas' answer). I personally prefer $(), but some non-POSIX shells such as tcsh don't support it (demo). I suggested an edit to fix the issue with sg, but left the backticks to respect the author's preference.
    – tom
    Commented Jun 9, 2022 at 5:23

Using newgrp command solved problem for me:

newgrp <GroupName>

This blog post has detailed explanation.


Groups are usually enumerated at login, there is no way I know of to force it to re-do group enumeration without logging out and back in again.

Many answers voted up here seem to use a workaround that invokes a new shell with fresh environment (same as logging in again). the parent shell and all other continuously running programs will generally not receive the new group membership until being re-invoked from a fresh shell usually after clean logout and login.

  • Truthfully, I'm pretty sure that this isn't true - I'd found a way to do it before on a Linux box. However, for the life of me, I cannot remember what the command was. If I find it, I'll post it. Edit: Just found it, I'm posting it as an answer.
    – user74554
    Commented Jan 30, 2012 at 16:11
  • 3
    Thank you for pointing this out, this is also my understanding. Every other answer here simply opens a new shell, no matter whether it replaces one open shell or restarts screen or whatever. There is no magical panacea to issue a command or script and have every running session, including your X session, reflect the new group memberships.
    – scravy
    Commented Sep 13, 2019 at 9:30

You can do this.

Add as many groups as you want using usermod -G. Then, as the user with a running session, run newgrp - with just the '-' argument.

This reinitializes the group id to the default, but it will also set the secondary groups as well. You can verify this by running groups from the current session, before and after the usermod and the newgrp.

This has to be run from each open session - I don't know much about screen. However, if it's possible to iterate over all open sessions and run newgrp, you should be good. You won't have to worry about knowing the groups or the group IDs.

Best of luck to you.

  • 14
    tried on an xterm within an X session but it did not work
    – dwery
    Commented Jul 10, 2012 at 19:27
  • 4
    tried in on a session in tmux and it did not work there either
    – Michael
    Commented Feb 12, 2013 at 3:32
  • 3
    Tried on Amazon linux 2, it did not work Commented Mar 28, 2018 at 14:53
  • 3
    newgrp - starts a new shell process Commented Apr 24, 2018 at 13:05
  • 1
    In light of your comment on the answer by Mister_Tom, this is, as all of the other answers, a workaround. Mister_Tom's answer is still correct.
    – scravy
    Commented Sep 13, 2019 at 9:28

If you need to preserve your environment variables, try exec sudo -E -u "$USER" "$SHELL". exec replaces the current shell with the new one, -E preserves the environment, -u "$USER" changes user to yourself, and $SHELL specifies the shell is the command to use.

  • Seems to work pretty fine!
    – 4wk_
    Commented Jan 6, 2023 at 9:31

To respawn the terminal but keep GUI applications working, try exec su -p $USER. This preserves environment variables (including Xorg stuff) but reloads groups.

Alternatively remove exec to spawn a subshell instead of replacing the current shell.

  • interesting! this is one of few or the only session, that doesn not spawn a new session.
    – Frank N
    Commented Dec 26, 2020 at 11:24

To summarize:

exec newgrp <newlyaddedgroupname1>
exec newgrp <newlyaddedgroupname2>
exec newgrp -

Using 'exec' means replace the existing shell with the new shell started by the newgrp command (so exiting from the new shell logs you out).

The final newgrp - is needed to restore your normal primary group, so files you later create will have that as their group owner.

Note: The original poster's question was how to make newly-added groups visible in existing processes. The gpasswd and usermod commands don't affect existing processes; newly-added (or deleted!) groups appear in (disappear from) your account, i.e. in the /etc/group and /etc/gshadow files, but permissions for existing processes aren't changed. To remove permissions you have to kill any running processes; newgrp - will not re-read /etc/group and reset the group list; instead, it seems to just use the groups previously associated with the process.

  • By the way, exec su - <username> can be used to get a new login shell with groups set, but that won't work in scripts because a new shell will read commands from the terminal. You could use su -c "command ..." <myusername> to restart your script, but the resulting process has no controlling terminal and so an error will occur if a screen editor or other interactive command is attempted.
    – jimav
    Commented Feb 10, 2017 at 23:30
  • Why was this downvoted? Can someone explain what's bad about it, because it was what occurred to me and I think I like it best?
    – jasonmp85
    Commented Mar 8, 2017 at 0:02
  • Gah, I voted it up before testing. newgrp - does not replace the "primary group". Patrick Conheady's answer is the best one here, as it neither forks nor changes the primary group.
    – jasonmp85
    Commented Mar 8, 2017 at 0:30

There are already a lot of correct answers, however this worked fine for me on Debian based systems:

sudo -s -u ${USER}

This command will do the job in a sudo environment.

The -sflag run the shell as configured in the /etc/passwd file.


This does the trick if you have sudo and it can save you from entering your password one more time in some cases:

sudo su $USER
  • only thing that worked for me trying to get docker to work without restarting because I had a huge job running Commented Mar 11, 2020 at 1:57

I couldn't get the newgrp command to work. I'm not sure if this depends on /etc/sudoers, but I normally have to type my password for sudo, and this worked without requiring my password:

[leo60228@leonix:~]$ groups
users wheel

[leo60228@leonix:~]$ sudo echo hi
[sudo] password for leo60228:

[leo60228@leonix:~]$ sudo -k # reset sudo timeout

[leo60228@leonix:~]$ exec sudo -i -u $(whoami) # no password necessary

[leo60228@leonix:~]$ groups
users wheel docker

I had similar issue but also for not logged-in users. Restart of nscd didn't help, but executing this command did: nscd -i group. That should instruct nscd (caching daemon) to reload the groups file.


The accepted answer is correct, but it's only good for interactive shell, and won't work in scripts. To solve this I used this:

newgrp <GroupName> << END

This will open a new session with the updated groups, run the command, and then it will bring you back to the first session, where you still not in the group. This will allow you to create the group and use it in the same script.


I needed to do this in a shell script (script adds current user to a group, runs later commands that require that group membership). The newgrp command is brittle in that it can only run a new shell rather than an arbitrary command (I want to re-run the current shell script with original commandline args).

Here's my solution, which uses lots of bash-isms: (note the surrounding script needs some sort of branch to only run this function if the required group is not currently active):

(note: the script implies that it ran sudo adduser $user docker, which means it could also just run sudo docker everywhere instead of docker but that was undesirable in this case)

# save these for later

# This function is a little insane. The problem is this: user running
# this script is not a member of docker group, but used 'sudo' to add
# themselves to group. Without logging out and back in, the only way
# to gain access to that group is via the 'newgrp' command, which
# unfortunately starts a new shell rather than an arbitrary command...
# Also, we're going to newgrp twice: first to add the new group and
# again to restore the original group (but the new group remains in
# the 'groups' output).
# So this horrendous hack dups stdin to fd3 for later. Then runs
# 'newgrp' piping in a script that runs 'newgrp' a second time, piping
# in another script that restores stdin from fd3 and execs the
# original command...
restart-newgrp-newgrp() {
  # dup original stdin to fd3
  exec 3<&0

  local group="$1"
  local command="$0"
  local arg
  for arg in "${ORIGINAL_ARGS[@]}"; do
    printf -v command "%s %q" "$command" "$arg"

  # restore original stdin from fd3; also replace any single-quote in
  # command with '"'"' to embed it in a single-quoted string
  local script
  printf -v script "exec newgrp %q <<<'exec <&3-; exec %s'" "$(id -gn)" "${command//\'/\'\"\'\"\'}"

  exec newgrp "$group" <<<"$script"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .