LPIC-2 File Sharing and Samba Practice Question
A company uses a Samba server (version 4.12) on Ubuntu 20.04 to provide file sharing for the engineering department. The server has a share [projects] defined in smb.conf with the following parameters: `path = /srv/projects`, `valid users = @engineers`, `read only = no`, `create mask = 0660`, `directory mask = 0770`. All users in the engineers group can authenticate and list the share contents but they report that they cannot create new files or modify existing ones. The command `ls -ld /srv/projects` shows `drwxrwxr-x`, and the directory is owned by root:engineers. The sysadmin has confirmed that the file system permissions on /srv/projects are set to 2775, but the setgid bit does not appear in the ls output. Additionally, users are able to create files in other shares on the same server that are configured similarly. Which of the following is the most likely cause and solution?
⚠ Common exam trap
The trap here is that candidates focus on the create mask or writable settings, overlooking that the real issue is group ownership inheritance—a subtle but common Samba misconfiguration where the setgid bit is missing or not enforced, causing new files to be owned by the user's primary group instead of the share's group.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The directory lacks the setgid bit and new files do not inherit the engineers group. Add `force group = engineers` and `inherit permissions = yes` to the share configuration.
The directory /srv/projects lacks the setgid bit (shown as 2775 but ls output shows drwxrwxr-x, indicating the setgid bit is not effective), so new files and directories created by users in the @engineers group will be owned by the user's primary group (typically the user's default group) rather than the engineers group. Adding `force group = engineers` forces all new files to have the engineers group, and `inherit permissions = yes` ensures that the directory's permissions and setgid behavior are propagated to new subdirectories, resolving the permission mismatch that prevents writes.
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 valid users parameter should be changed to include '%engineers' instead of '@engineers'.
Why it's wrong here
The '@' prefix is correct for referring to a group in valid users. '%' is not used.
- ✗
The create mask is too restrictive. Change it to 0666 to allow more permissions.
Why it's wrong here
The create mask 0660 already grants group write. A mask of 0666 would allow world-writable files, which is a security risk.
- ✓
The directory lacks the setgid bit and new files do not inherit the engineers group. Add `force group = engineers` and `inherit permissions = yes` to the share configuration.
Why this is correct
This forces new files to have the engineers group and propagates the setgid behavior, ensuring group write for all users.
- ✗
The parameter `read only = no` is being overridden by a global setting. Add `writable = yes` to the share.
Why it's wrong here
`read only = no` and `writable = yes` are equivalent. There is no overriding issue.
Visual reference
Go deeper
Related to this question
About these practice questions
This LPIC-2 question is part of Courseiva's 507-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-2 practice question is part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LPIC-2 exam.