USING newgrp TO EFFECT TEMPORARY SOLUTION IN NEW SHELL:
newgrp command can be used. It enabled the user to temporarily (in a new shell) change their primary group to a specified value.
user1 group to
sudo usermod -a -G user1 user2
user2% newgrp user1
user2's primary group will immediately be
user1, and a file write will result as
user1 being the group owner. However, the primary group specified in
/etc/passwd is not changed.
newgrp user1 again
user2% newgrp user2
user2's primary group will immediately be set back to
user2 will still belong to group
user1. This is the effect that was initially expected from
sudo usermod -a -G user1 user2, but did not happen immediately. In this state a file write will result as
user2 being the group owner.
- Note: Each invocation of
newgrp results in a new shell. In
bash this results in incrementing the value of the environment variable
SHLVL by 1. After exiting the shell created by
newgrp the effects are reversed, with no side effects. For that reason there still might conceivably be use cases where logout/reboot or some other solution is required, so I leave my previous answer below, which worked when logout didn't work, and avoided having to reboot. However, in practice, I find that
newgrp is sufficient to cover every use case I face.
"PERMANENT" SOLUTION without REBOOT WHEN LOGOUT DIDN'T WORK
I found that the selected answer's suggestion
user2 needs to log out and back in. ... The kernel starts the init process (the first process after boot) running as root, and every process is ultimately descended from that process [and so it needs to be killed by logging out]
didn't work in Ubuntu 20.04 from the "Logout" GUI option, and that after logging out and back in this 'init' process with an older start time was remaining
root 1 0.0 0.1 168096 11744 ? Ss 12:45 0:02 /sbin/init
Killing that might solve it, but I didn't do that, instead I killed this user process which also had an older timestamp
craig 1790 0.0 0.0 169360 3784 ? S 12:46 0:00 (sd-pam)
simply because of my weak understanding that "pam" is a module for authenticating users. It worked, and thereafter
id showed self with the correct group permissions.
Failure of logout to solve problem might (or might not) be related to
systemd. I think maybe so after reading this.