Learn Samba - Basic Shares & Permissions

#Introduction

The basic configuration from episode 3 already created your first share. In episode 4 we go up a level: building a data share that's truly used in production — with correct owner mapping and an honest understanding of how the two permission layers work together. This is the most important episode for avoiding the "why is the file I wrote owned by a strange user?" frustration that haunts every beginner Samba administrator.

#Basic Share: [data]

#Building a Production-Ready Share

A data directory usually has different characteristics from a public share: it needs read-write access, is managed by a team, and has clear ownership. Prepare the directory and its share:

sudo mkdir -p /srv/data
sudo chown root:staff /srv/data
sudo chmod 2770 /srv/data
ls -ld /srv/data

chmod 2770 turns on setgid (bit 2) so new files inherit the staff group, and gives full access only to owner/group. This is the foundation of collaboration: all staff members can read-write without trampling each other's rights. Here's the share configuration:

[data]
   path = /srv/data
   browseable = yes
   writable = yes
   valid users = @staff
   force user = arman
   force group = staff
   create mask = 0660
   directory mask = 2770

Let's break down each line:

• path = /srv/data: the directory being shared.
• browseable = yes: the share appears in the list when browsing the network.
• writable = yes: allow write operations from clients (synonym of read only = no).
• valid users = @staff: only members of the staff group may access (the @ prefix denotes a group).
• force user = arman: every file created by a client becomes owned by user arman.
• force group = staff: every file inherits the staff group.
• create mask/directory mask: force file (0660) and directory (2770) permissions to stay aligned with the collaboration design.

#Why force user/group

The classic problem: a Windows client connects as arman, but the files it creates end up owned by another user because Samba uses the connect identity when writing. force user/force group standardizes ownership — no matter who logs in, files always end up owned by arman and the staff group. This isn't a "hack"; it's a standard pattern in collaborative shares so filesystem permissions stay predictable. Use it wisely: force user overrides real ownership, so don't point it at root without a strong reason.

#Two Permission Layers

#Layer 1: Share Options (Samba)

The options in the share section — valid users, writable, read only, write list — are the first gate. Samba checks these before processing any file operation. valid users = @staff means users outside staff can't even open the share, regardless of their filesystem permissions.

#Layer 2: Filesystem Permissions (Linux)

Even if the Samba layer is passed, the Linux kernel still checks filesystem permissions (mode bits, owner, group, and ACLs). These are two stacked gates: access = pass share options AND pass filesystem permissions. If either one denies, the operation fails — often without a clear error message on the client side.

klien --> valid users? --> writable? --> filesystem permission? --> OK

A real example: writable = yes in the share, but the /srv/data directory is chmod 755 and owned by root. User arman can open the share but fails to create files. You get an "Access denied" error in Windows Explorer even though "the Samba config is correct". This is exactly the case where testparm doesn't help — the problem is in the second layer.

#Restricting Access: valid users vs write list

#Granular Settings

Sometimes you want everyone to be able to read, but only some to write. That's where write list works together with read only:

[data]
   path = /srv/data
   read only = yes
   write list = @editors, budi

• read only = yes: baseline — all users are read-only.
• write list = @editors, budi: exceptions — the editors group and user budi may write.

This is the least privilege pattern we'll emphasize again in episode 15: grant the minimum capability needed, then open up explicitly. Compare:

• valid users → determines who may enter the share.
• write list → determines who may write among those already admitted.
• read only/writable → the share-wide default write access.

#Common Pitfalls

• "Writable but can't write": almost always filesystem permissions, not share options. Check with sudo -u <user> touch /srv/data/test.
• Files owned by an unexpected user: add clear force user/force group.
• Setgid lost: chmod 2770 on the parent directory so new files stay in the right group; directory mask also needs the setgid bit.
• valid users blocks too much: forgetting the @ prefix on a group causes a Failed to find a POSIX uid error in the logs — write @staff, not staff.

#Verification

Test with the command-line client (with a user registered in episode 5):

smbclient //localhost/data -U arman -c "mkdir testdir; ls; exit"
ls -ld /srv/data/testdir

If testdir appears and is owned by arman:staff, both permission layers are working correctly. This is a moment worth a small celebration: your first production share is alive.

#Closing

Key takeaways:

• A [data] share with path, browseable, writable forms a production-ready basic share.
• force user/force group standardize ownership of client-created files.
• Access = pass share options AND filesystem permissions — two stacked gates.
• valid users determines who enters; read only + write list determines who writes.
• Always verify at the filesystem level (sudo -u <user> touch) before blaming the Samba config.

In episode 5 next, we'll cover user management & smbpasswd: synchronizing system users with the Samba password database, smbpasswd -a, pdbedit -L, the tdbsam storage format, username map for aliases, and account flags. After this episode, you can create users who can actually log into your shares.