linux file permissions


I've created a file share on a Linux Mint Server (Ubuntu 12.04).    The permissions are set to 777.  

The share owner is root, the group users.  Others can "create and delete files."

My users can all browse the folder and create and delete new folders from their client machines.

However, whenever a client creates a new file, the owner is root!  As a result, the new file is read-only!

I've tried the sticky bit (chmod g+s).  No joy.

Can you suggest a way to grant full access to this share?
Glen GibbOwnerAsked:
Who is Participating?
farzanjConnect With a Mentor Commented:
Is 'users' the group of the folder where this file is created?  If so, this is the expected behavior.

You can use filesystem ACLs at least to set the default permissions.

setfacl -m -d u::rwx /path/folder
setfacl -m -d g::rwx /path/folder
setfacl -m -d o::rwx /path/folder

Not good for security view point but at least would know what is going on.
BenefordConnect With a Mentor Commented:
Is this shared with Samba?

You may have the admin users option set (making all users run as if they are root), and you may want to have the force user option set (making all users access as if they are some (other) user).
Exactly what you do will depend on your security requirements, but if you're happy with 777, that's probably not an issue.

Check out Chapter 16 (esp 16.2) of Samba documentation (, learn samba\Official HOWTO)
Glen GibbOwnerAuthor Commented:
This is a Samba share.

I've set "force user = capt", I've made "capt" the owner of the folder.  But my client still creates files as "root."

Any other ideas?

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

>> I've tried the sticky bit (chmod g+s).  No joy.

This command is used for GID not sticky bit.  Sticky bit is chmod o+t.

Secondly sticky bit is not meant for this purpose.  With it only the user can delete his own file.
Glen GibbOwnerAuthor Commented:
OK, but how to I allow the user to create his own file?  Shouldn't the 777 take care of that?

But it doesn't!

NO.  Absolutely not.  777 is a bad practice, it appears to be a quick practice to fix "everything" but it is not.  It has nothing to do with the ownership of created files/folders.  It allows every one to read, write and execute.

If the new files are read only, perhaps they don't have read permissions for "others".   Files have the user and group ownership of the effective user and group of the creating process.  The old method for default file permissions (not ownership) is umask.

The old mechanism of inheriting owership of group is applying GID as you were doing above on this folder where the files are created.  If you do chmod g+s folder, any file in this folder will have the group of the folder rather than the process that created it.
Glen GibbOwnerAuthor Commented:
Hi, Experts,

Still no solutions?  I've tried the chmod g+s to my folder, but still a network client creates a file that has root as its owner, users as its group (read-only) and others w/ read-only access as well.  

Folder creation seems fine.

I want this as a public folder, where everyone can create, delete, and update files and folders!

Yes, I'm a victim of ignorance, but you are the Experts!


Glen GibbOwnerAuthor Commented:
I'll give it a try.  Even from the server itself, although applying chmod -R a or g+rwx /public,
creating a new file gives read/write permissions to the owner, but the  group and other are read-only.

Strangely, Win boxes have no troubles at all with file creation.  Just Linux boxes produce this.
Glen GibbOwnerAuthor Commented:
setfacl: Option -m: Invalid argument near character 1

Can you tell me what happened here?
Glen GibbOwnerAuthor Commented:
Removed the -d from the setfacl and it executed.
Glen GibbOwnerAuthor Commented:
No change.  Folders have rwx for owner, group and others.  New files and folders are rwx for owner.  Group and Others are read-only.
No, that changes the meaning.

setfacl -m d:u::rwx,d:g::rwx,d:o::rwx directory_name

Open in new window

Glen GibbOwnerAuthor Commented:
getfacl: Removing leading '/' from absolute path names
# file: media/Docs/geFiles
# owner: glen
# group: users
# flags: -s-

This sort of tells me my Linux user has rwx permissions.  But using Nautilus, no go.  Is Nautilus the culprit?
With these permissions, any file now created should be readable or writable by anyone.  You could also have implement based on groups only.  It would NOT change the user ownership tough.  User ownership will be the same as the process/program's user ownership.  If GID is set, then group ownership should be same as ownership of folder.
Glen GibbOwnerAuthor Commented:
Did the chmod g+s /...
Ran setfacl (as above).

Now file creation on the server works as hoped.  Files and folders have rwx for all.

However, on the Linux clients, no change.  Owner has rwx, g and o have r.
I do not understand what clients you are talking about.  What kind of client?  Samba clients?  If you are talking about Samba share, did you give writable a "yes".  In case of Samba, look at your share permissions.
Glen GibbOwnerAuthor Commented:
Just to illustrate, here's my smb.cnf for the public share:

path = /media/Docs/geFiles
comment = Home network shared files
valid users = www-data glen glen@DevBox ftp smbguest capt steve proftpd
write list = www-data glen glen@DevBox proftpd ftp smbguest capt steve
admin users = www-data glen proftpd ftp root smbguest capt steve
force group = users
public = yes
available = yes
writable = yes
guest ok = yes
printable = yes
locking = yes
strict locking = no
browsable = yes
What makes you think that the files are readonly?  Can you show what is read only?
Glen GibbOwnerAuthor Commented:
Thanks, Experts.

I solved the problem by re-examining the shared file in Webmin.  Seems that the share had permissions for printers and files, and things were fairly complex.  I deleted the share, put the printers in /var/spool/samba and re-created the file share.

Works great.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.