chmod 775 (rwxrwxr-x)

Q: How do I stop group members from deleting each other's files in a 775 directory?

Add the sticky bit with chmod 1775 . Then a user can only delete or rename files they own, even though the directory itself stays group-writable — the same protection /tmp uses.

The owner and group can read, write, and execute; others can read and execute but not modify.

Note: this grants group or shared write access — fine for team directories, but make sure that is what you intend.

When to use 775

Shared team directories where the whole group needs to create files. 775 (rwxrwxr-x) gives both owner and group full read/write/execute, so any group member can add, edit, and delete entries in a common workspace — e.g. a /srv/shared or project drop folder for a developers group. Others can still read and traverse but not write.
Collaborative document or asset roots under a shared group. A directory where several people commit builds, uploads, or reports and all must be able to write, while read-only visibility for other accounts is acceptable. 775 is the canonical 'group-writable, world-readable' directory.
Local dev or staging trees for a small team. On a non-public box, a folder where everyone in the project group needs equal write access without involving root for each change — pairs with the setgid bit so new files inherit the group.
Package/plugin directories an admin group co-maintains. Where multiple operators in a group must add or update contents while the running service (as 'others') only needs read/traverse.

Common mistakes & gotchas

Group-writable means any group member can delete others' files — set the sticky bit. In a plain 775 dir, anyone in the group can rm files they don't own. For a shared drop folder, add the sticky bit (chmod 1775) so users can only delete their own entries, the way /tmp works.
New files won't inherit the group unless you set setgid. Without setgid, a file created in a 775 dir gets the creator's primary group, breaking shared access. Use chmod 2775 (setgid) so every new file and subdir inherits the directory's group, keeping the collaboration intact.
World-readable is the silent risk. The trailing 5 grants others read and traverse — fine for non-sensitive shared work, dangerous if the directory ever holds credentials, customer data, or private keys. If the world shouldn't see it, drop to 770 (rwxrwx---).
Group membership and group ownership must both be right. 775 is useless for collaboration if the intended teammates aren't in the directory's group, or if the group column is the owner's personal group. Verify with ls -ld and fix the group with chgrp -R before relying on the write bit.

775 vs the alternatives

755 (rwxr-xr-x) when only the owner should write and the group is read-only — the safer default for single-maintainer dirs. Step up to 775 only when the whole group genuinely needs to create and modify files.
770 (rwxrwx---) when the group needs write but the world should see nothing. It's 775 minus the world read/traverse bits — choose it whenever the shared content is sensitive.
2775 (setgid + rwxrwxr-x) is the production-grade form of 775 for real collaboration: new files inherit the directory's group so shared access doesn't decay. Prefer it over bare 775 for any long-lived team folder.

Set it with chmod

Apply this permission to a single file:

chmod 775 filename

Or apply it recursively to a directory and everything inside it:

chmod -R 775 directory/

The same thing in symbolic form:

chmod u=rwx,g=rwx,o=rx filename

Frequently asked questions

What does chmod 775 mean?

chmod 775 sets rwxrwxr-x: owner and group both get full read/write/execute, while others get read and execute (traverse/list) only. It's the standard permission for a directory a whole group needs to write to, shared read-only with everyone else.

When should I use 775?

Use it on a directory where multiple members of a group must create, edit, and delete files collaboratively — shared project, build, or upload folders. Avoid it for sensitive data, since others can still read and traverse.

How do I stop group members from deleting each other's files in a 775 directory?

Add the sticky bit with chmod 1775. Then a user can only delete or rename files they own, even though the directory itself stays group-writable — the same protection /tmp uses.

Why do new files in my 775 directory lose group access?

Without the setgid bit, new files take the creator's primary group instead of the directory's group. Set chmod 2775 on the directory so all new files and subdirectories inherit the shared group automatically.

Other common permissions

Or build any permission with the interactive chmod calculator.

chmod 775 — what rwxrwxr-x means

Permission breakdown