EX200 Manage users and groups Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The directory lacks the setgid bit; set it with 'chmod g+s /var/backups'.

  Why it's wrong here

  The setgid bit on a directory only controls the group ownership inherited by newly created files; it does not govern whether a user has permission to create files at all. If the user already has write and execute access on the directory (through user, group, or other bits), they can create entries even without the setgid bit. Because the observed error is 'Permission denied' during creation, the cause must be missing write permission or a security mechanism, not the absence of setgid.

• ✓

  The user needs to log out and log back in to refresh their group membership.

  Why this is correct

  Linux determines a user's supplemental groups at login time from the /etc/group database and stores them in the process credentials via initgroups(). When a user is added to a new group after their current login, existing shells and daemons keep the old group set; simply editing /etc/group does not update running sessions. The user must end the session and log in again so that login(1) or systemd user session reinitializes the supplementary groups, allowing access to files and directories that require that group.

• ✗

  The user's umask is too restrictive, preventing file creation. Change the umask to 002.

  Why it's wrong here

  The umask is a per-process mask that determines which permission bits are turned off when creating a file or directory; for example, 022 yields 755/644 defaults. It never prevents creation from succeeding—if the process has write permission on the parent directory, the file is created regardless of the umask. A 'Permission denied' on creation is invariably caused by a lack of write/execute permission on the directory, an ACL, SELinux policy, or a read-only mount, not by umask. Changing umask to 002 only affects the default permissions, not whether creation is permitted.

• ✗

  The user should use 'newgrp backup' to switch to the backup group temporarily.

  Why it's wrong here

  The user's current shell was started after login, so the backup group membership (listed in /etc/group) is already inherited as a supplementary group. The `Permission denied` therefore stems from a different cause—such as an SELinux context, ACL, or filesystem mount option—not from an absent group. Newgrp changes only the effective primary GID, which does not address this other underlying issue. It is tempting because newgrp is the standard tool when a user lacks the group in their current session (e.g., a group was added after login and they need a temporary switch without logging out).

Go deeper

Related to this question