Finding a good solution for sharing files between Linux users is a nightmare.

If using a unique UID is not a problem, it’s the most simple solution. All clients access files with the same UID. This way you cannot know who does what, and users cannot fine tune access rights.

The problem: default umask is ALWAYS 0022, so that any created file will get rw– r–– r–– permissions. Only the owner can write. Nobody else. To share files, a group must have write access.

You can change the umask. For command line, you set it in .bashrc or .profile, or /etc/profile for all users. For a SFTP share, you can set it with a trick. For Apache HTTP server, you can set it with /etc/apache2/envvars under Debian.

If file sharing is only done via on service, changing umask is simple, otherwise it’s not that easy. And even if you change umask for all services, nothing is perfect: for example it doesn’t work with Nautilus and SFTP. Some clients drop files and issue a chmod right after: the hell. You can also try the power of POSIX ACL to force permissions. But problems still remain with some clients.

And for the umask, maybe you don’t want all files to be dropped group writable. Maybe you want more granularity on permissions.

So I abandonned the idea of fixing the problem at the source in favor of some trick AFTER file creation.
The most simple solution is the cron task: every X minutes, run chmod -R g+w on the directory. This way permissions are not fixed immediately, but asynchronously. And it adds a (very) little more load to your system.

My solution uses inotify to listen for file changes and force permissions when files are created:

inotifywait listens for events in the /tmp/mytest directory. When a file is created, it’s displayed on standard output. Then each fileline is read by the while loop and permissions are changed. g=u gives the group the user’s permissions (with g+w, if the user drops a file with rw– ––– –––, permissions will be rw– –w– –––).

You can now test file/directory creation and copy. mkdir -p a/b/c/d/e shoud also work.

14 Comments

Hello,
Yes, in fact I tried incron before, but never managed to make it work :
My incron task was never taken in account. I searched for some log or debug in the daemon with no success.
Maybe I should try it again.

Great tip, but this is not gonna work if you create a file with a newline in its name (although I am very contrary to these bizarre filenames).
Don’t know how to fix it, though, I don’t see a way to use a custom file separator in inotifywait’s output.
Any ideas?

I had trouble getting this to work when Using Nautilus to transfer files over to an NFS share.
It would only work when creating new Folders, but not when copying/moving.

So I did some digging and here is the command that works (note that I have not used the one for trailing spaces or backstlashes:

****************************************
inotifywait -mrq -e CREATE -e CLOSE -e MOVED_TO –format %w%f /home/alex/autochown/ | while read FILE; do `sleep 1` && chmod g=u “$FILE”; done
****************************************
Explanations of modifications:
-e CLOSE and -e MOVED_TO are the last events that Nautilus does when creating new files or copying/moving files around. This way, permissions are set after Nautilus finished the copy.

the “sleep 1″ is because when Nautilus creates a file, it changes the permissions right away. The issue is that the NFS server machine will get into a “race condition” and will change the permissions a few milliseconds before Nautilus will (all this happens in less than 0.5 seconds).

To work around this, we add a 1 second delay to the chmod command. This might only be a problem is the rate at which files are created in the folder is more than 1 per second for a very long time.

dear Alecz!
Nautilus is working on his own cunning scenario – I am agree with this. But sleep 1 – this is not a good solution, because we get timeout for each file/dir for a 1 second (as is in you example).
This is a very significant reduction in performance.