• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 920
  • Last Modified:

linux file permissions

Experts,

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?
0
Glen Gibb
Asked:
Glen Gibb
  • 11
  • 7
2 Solutions
 
BenefordCommented:
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 (www.samba.org, learn samba\Official HOWTO)
0
 
Glen GibbAuthor 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?

Capt
0
 
farzanjCommented:
>> 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.
0
Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

 
Glen GibbAuthor 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!

Capt
0
 
farzanjCommented:
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.
0
 
Glen GibbAuthor 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!

Help!

Capt
0
 
farzanjCommented:
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.
0
 
Glen GibbAuthor 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.
0
 
Glen GibbAuthor Commented:
setfacl: Option -m: Invalid argument near character 1

Can you tell me what happened here?
0
 
Glen GibbAuthor Commented:
Removed the -d from the setfacl and it executed.
0
 
Glen GibbAuthor 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.
0
 
farzanjCommented:
No, that changes the meaning.

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

Open in new window

0
 
Glen GibbAuthor Commented:
getfacl: Removing leading '/' from absolute path names
# file: media/Docs/geFiles
# owner: glen
# group: users
# flags: -s-
user::rwx
group::rwx
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx

This sort of tells me my Linux user has rwx permissions.  But using Nautilus, no go.  Is Nautilus the culprit?
0
 
farzanjCommented:
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.
0
 
Glen GibbAuthor 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.
0
 
farzanjCommented:
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.
0
 
Glen GibbAuthor Commented:
Just to illustrate, here's my smb.cnf for the public share:

[docs]
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
0
 
farzanjCommented:
What makes you think that the files are readonly?  Can you show what is read only?
0
 
Glen GibbAuthor 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.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 11
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now