Linux & Bash · Part I · Module 5 · Permissions, Ownership and Execution

Ownership and Shared Directories

Chapter 5.3 changed what may be done to a file. This chapter changes who it belongs to — and then uses that to solve a problem every team on a shared machine meets within its first week. Two people need to work in the same directory. They set it up the obvious way, it half-works, and within days they are copying files into each other's home directories to get around errors nobody fully understands. The arrangement that actually works is three settings, and each of them fixes a specific failure that the previous one leaves behind.

Foundation16 min readLinuxPart IFundamentalsPermissionsCollaboration

Part I · Module 5 · Chapter 5.4 · Ownership and Shared Directories

1. Two Facts Recorded on Every File

Chapter 2.5 showed them and Chapter 5.1 explained why they matter:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -l shared_notes.txt
-rw-rw-r-- 1 engineer design 8192 Mar 25 11:05 shared_notes.txt

Owner: engineer. Group: design. Those two fields are what Chapter 5.1's three questions are asked against, so changing either changes who falls into which category.

Where they come from when a file is created:

the owner is whoever created it — you;
the group is normally your primary group, the gid= from id.

That second default is the one that causes trouble in §5, and it is worth noticing now: a new file does not get the group of the directory it was created in. It gets your group.

2. `chgrp` — Changing the Group

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -l data.txt
-rw-r--r-- 1 engineer engineer 2048 Mar 25 11:10 data.txt

$ chgrp design data.txt

$ ls -l data.txt
-rw-r--r-- 1 engineer design 2048 Mar 25 11:10 data.txt

The group changed from engineer to design. Everyone in design now falls into Chapter 5.1's second category for this file rather than the third.

Two conditions must both hold:

you must own the file;
you must be a member of the group you are changing it to.

You cannot hand a file to a group you are not in. id from Chapter 5.1 tells you which groups are available to you.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ id
uid=1001(engineer) gid=1001(engineer) groups=1001(engineer),2000(design),2001(verif)

Three groups, so chgrp design and chgrp verif will work and nothing else will.

Recursively, for a tree:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chgrp -R design project/

3. `chown` — and Why You Cannot Use It

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chown priya data.txt
chown: changing ownership of 'data.txt': Operation not permitted

This refuses even though you own the file.

That surprises people, and the reason is deliberate: an ordinary user cannot give a file away. On most Linux systems only root may change a file's owner.

The reasoning is about accountability rather than trust. If you could hand files to other people, you could place a file in somebody's home directory and make them responsible for it — for disk quota, for whatever it contains. Making ownership transferable only by an administrator closes that off.

chown can also set both at once, which you will see in instructions written for administrators:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chown priya:design data.txt     # owner priya, group design — needs root

The practical consequence for you: when you need another person to own something, you do not transfer it. They make their own copy, which makes them the owner of the new file:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# priya runs this
$ cp /shared/project/data.txt ~/data.txt

Chapter 3.2's cp creates a new file, and the creator owns it.

One form of chown that does work

Changing the group through chown is allowed, because it is the chgrp operation under another name:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chown :design data.txt

The empty part before the colon means "leave the owner alone". Same rules as §2 — you must own the file and be in the group.

4. Setting Up a Shared Directory: First Attempt

Here is the problem the chapter exists for. Two engineers, engineer and priya, both in the design group, need to work in one directory.

The obvious attempt:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ mkdir /projects/alu
$ ls -ld /projects/alu
drwxr-xr-x 2 engineer engineer 4096 Mar 25 14:00 /projects/alu

Chapter 5.2 reads that as 755: the owner may do everything, the group and everyone else may list and traverse. So priya can look and cannot create anything.

Two things are wrong. The group is engineer, which is a group of one, so priya is in the everyone-else category. And even if she were in the group, the group has no write permission, so she could not add a file.

Fix both:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chgrp design /projects/alu
$ chmod g+w /projects/alu

$ ls -ld /projects/alu
drwxrwxr-x 2 engineer design 4096 Mar 25 14:00 /projects/alu

Now priya is in the group, and the group may write. She can create files. This looks solved.

5. Why the First Attempt Fails Anyway

It works for about a day.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# priya creates a file in the shared directory
$ cd /projects/alu
$ touch priya_notes.txt

$ ls -l
-rw-r--r-- 1 priya priya 0 Mar 25 14:30 priya_notes.txt

Look at the group: priya, not design.

This is §1's default doing exactly what it said it would. A new file takes the creator's primary group, and nothing about being created inside a design directory changes that.

The consequence for engineer:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ echo "edit" >> priya_notes.txt
bash: priya_notes.txt: Permission denied

He is not the owner, and he is not in the group priya, so he lands in the everyone-else category, which has read only.

This is the precise point at which teams start emailing copies around. The directory is shared, the files in it are not, and the failure appears days after the setup looked correct.

6. The Setting That Fixes It

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chmod g+s /projects/alu

$ ls -ld /projects/alu
drwxrwsr-x 2 engineer design 4096 Mar 25 14:00 /projects/alu

Note the s where the group's x was. Chapter 5.2 mentioned that letter and deferred it; this is what it does.

On a directory, g+s means: anything created in here takes the directory's group, not the creator's.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# priya again, after the change
$ touch priya_notes2.txt

$ ls -l
-rw-r--r-- 1 priya design 0 Mar 25 14:45 priya_notes2.txt

The group is now design. Every member of the group is in Chapter 5.1's second category for that file, which is what everybody wanted from the start.

It applies to directories created inside too, and those inherit the setting itself — so a subdirectory made inside a shared area keeps working the same way without anybody remembering to set it.

The combined form, which is the canonical one-liner for this job:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chmod g+ws /projects/alu

Group write plus the group-inheritance bit, in one command.

7. The Piece Still Missing

Look at the mode on priya_notes2.txt again:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

-rw-r--r-- 1 priya design 0 Mar 25 14:45 priya_notes2.txt

The group is right. The group permissions are read only. engineer can read it and still cannot edit it.

The group was fixed; the mode was not. New files are created as 644, and nothing so far has changed that.

Which is the honest limit of this chapter: the group inheritance bit and a group-writable directory are two of the three settings, and the third is a default that has to be changed as well. That default is the umask, and it is Chapter 5.6 — the next chapter but one, and the reason it exists.

For now the complete picture, stated so you know what is still owed:

Setting	Fixes
`chgrp design dir`	the directory belongs to the team
`chmod g+w dir`	team members can create and delete entries
`chmod g+s dir`	new files inherit the team's group
a umask of `002`	new files are group-writable — Chapter 5.6

The first three are this chapter. Without the fourth, a shared directory is readable by the team and writable only by whoever created each file.

Repairing an area that already has the problem

Setting g+s affects only files created afterwards. Existing files keep whatever group they were given, so a directory that has been in use needs fixing once:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ chgrp -R design /projects/alu
$ chmod -R g+w /projects/alu
$ chmod g+s /projects/alu

Chapter 5.3's warning applies to the middle line: -R g+w adds group write everywhere, which is usually what you want in a shared area but is worth being deliberate about. It does not add execute, because g+w names only write — this is the symbolic form being precise in a way -R 775 would not be.

8. The Other Letter: Sticky Directories

One more you will see, since it appears on a directory you use constantly:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -ld /tmp
drwxrwxrwt 10 root root 4096 Mar 25 15:00 /tmp

A t at the end. /tmp is writable by everybody — which by Chapter 5.2's rule would let anyone delete anyone else's files, since deletion is governed by directory write permission.

The t prevents exactly that: in a sticky directory, you may only delete entries you own. It is what makes a world-writable scratch directory usable rather than chaotic.

You are unlikely to set it yourself. Recognising it on /tmp and knowing it is protective is enough for Part I.

9. Checking Access Without Guessing

When something in a shared area is refused, check the whole chain rather than the file alone — Chapter 5.2's --x demonstration is the reason:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -ld /projects /projects/alu /projects/alu/data.txt
drwxr-xr-x  8 root     root   4096 Mar 20 08:00 /projects
drwxrwsr-x  2 engineer design 4096 Mar 25 14:00 /projects/alu
-rw-r--r--  1 priya    design 2048 Mar 25 14:45 /projects/alu/data.txt

Read it top down, as engineer:

/projects — everyone else gets r-x. Traversable. Fine.
/projects/alu — group design, which includes you, gets rws. Fine.
data.txt — owner priya, group design. You are in the group, so you get r--. Read only.

The denial is located precisely, at the file, and the cause is §7's missing piece rather than anything about the directory. That is a diagnosis; chmod 777 would have been a guess.

10. Why This Matters in Engineering Work

Shared project areas are the normal case, not an advanced one. Any team working on the same design, scripts or results needs this arrangement, and the version that half-works is actively worse than no sharing at all — it produces intermittent permission errors that appear days apart and get worked around rather than fixed.

The workaround is the symptom. When people start copying files into their own home directories to edit them, the shared area has stopped working. That habit then creates its own problem: several divergent copies and no single authoritative one.

Ownership cannot be transferred, so plan around it. You cannot hand your results to a colleague. What you can do is put them somewhere the group can reach, with the group set correctly — which is this chapter.

Part II works in shared project areas throughout and assumes this arrangement exists.

11. Practice

Question 1. Which two fields on a file do Chapter 5.1's three questions get asked against?

Question 2. When you create a file, what owner and what group does it get?

Question 3. You own data.txt and are in groups engineer, design and verif. Which of chgrp design data.txt, chgrp admin data.txt and chown priya data.txt will work? Explain each.

Question 4. Why can an ordinary user not give a file to another user? Give the reasoning, not just the rule.

Question 5. A colleague needs to own a copy of your results. Describe what actually has to happen.

Question 6. A shared directory is drwxrwxr-x engineer design. priya, who is in design, creates a file. What group does it get, and why can engineer not edit it?

Question 7. Which single command fixes the problem in Question 6 for files created afterwards? What does the s in the listing mean?

Question 8. After chmod g+ws, engineer still cannot edit priya's new file. What is still wrong, and which chapter fixes it?

Question 9. /tmp is drwxrwxrwt. What would go wrong if the final character were x instead?

Question 10. Write the three commands that set up /projects/alu as a shared area for the design group, and say what each one fixes.

Answers

1. The owner field and the group field — the third and fourth columns of ls -l. Chapter 5.1's three questions compare your identity against exactly those two values.

2. It gets you as the owner and your primary group as the group. Neither is a choice you make at creation time; both come from your own identity.

3. chgrp design data.txt works — you own the file and you are a member of design, which are the two requirements. chgrp admin data.txt fails — you own the file but are not in admin, and you cannot assign a file to a group you do not belong to. chown priya data.txt fails — changing the owner requires root.

4. Because giving a file away would let you escape your own limits. If you could set another user as the owner, you could place a file inside their space, or exceed a quota by making your data belong to someone else, or plant something that runs with their identity. Ownership is the basis of every permission decision, so allowing it to be handed out would make the whole model unenforceable. Only root, which is already outside the model, may do it.

5. They have to make their own copy. You give them read access; they run cp, and the new file is created by them — so it is owned by them, with their primary group, as any file they create would be. Nothing is transferred; a second file comes into existence with a different owner.

6. The file gets priya's primary group, which is priya — not design. The directory's group plays no part in what a new file inside it gets. engineer therefore falls into the other category for that file, and the default mode for others does not include write, so engineer cannot edit it.

7. Set the setgid bit on the directory:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

chmod g+s /projects/alu

The s appears in place of the group's x in the listing (drwxrwsr-x) and means that files and directories created inside inherit the directory's group instead of the creator's primary group. Note it applies to things created afterwards; it changes nothing that already exists.

8. The group is now right, but the new file's group permissions still do not include write — that comes from each user's umask, which by default withholds group write. The chapter that fixes it is Chapter 5.6: everyone working in the area needs a umask such as 002 so that the files they create are group-writable in the first place.

9. The final t is the sticky bit, and in a world-writable directory it restricts deletion to the owner of each file (or of the directory). If it were x instead, /tmp would be world-writable with no such restriction — so any user could delete or rename any other user's files there, because removing a name is governed by the directory's write permission (Chapter 5.2). The sticky bit is what makes a shared scratch directory usable.

10.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

chgrp design /projects/alu     # the group that should own the area
chmod g+w /projects/alu        # members of that group may create and delete here
chmod g+s /projects/alu        # new files inherit the group instead of the creator's

The first makes the directory belong to the team; the second lets the team write in it; the third stops each new file reverting to its creator's primary group. A umask of 002 for everyone involved is the fourth piece, and it belongs to each user's environment rather than to the directory.

12. Remember

Every file records an owner and a group, and those two decide which of Chapter 5.1's categories applies to any given person.
A new file gets your user as owner and your primary group — not the group of the directory it was created in.
chgrp changes the group. You must own the file and be a member of the target group.
chown changes the owner and needs root — you cannot give a file away, for accountability reasons. The way to make somebody else the owner is for them to make a copy.
A shared directory needs three things: the right group, group write, and g+s so new files inherit the group.
chmod g+ws dir is the canonical one-liner, and the s appears where the group's x was.
g+s affects only files created afterwards. An existing area needs a one-off chgrp -R and chmod -R g+w.
That is still not quite enough: new files are created 644, so the group can read and not write. The umask is the fourth setting, and it is Chapter 5.6.
The t on /tmp restricts deletion to the owner of each entry, which is what makes a world-writable directory workable.
Diagnose with ls -ld on every level of the path. The denial is at exactly one of them.

The next chapter returns to a single file and the two conditions that must both be true before it will run — a question Chapter 1.7 raised, Chapter 2.3 half-answered, and this module can now finish.

Where this fits

Part of the Linux & Bash curriculum.

1. Two Facts Recorded on Every File

2. chgrp — Changing the Group

3. chown — and Why You Cannot Use It

4. Setting Up a Shared Directory: First Attempt

5. Why the First Attempt Fails Anyway

6. The Setting That Fixes It

7. The Piece Still Missing

8. The Other Letter: Sticky Directories

9. Checking Access Without Guessing

10. Why This Matters in Engineering Work

11. Practice

12. Remember

Where this fits

2. `chgrp` — Changing the Group

3. `chown` — and Why You Cannot Use It