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?
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> 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.
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.
ASKER
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
But it doesn't!
Capt
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.
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.
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
setfacl: Option -m: Invalid argument near character 1
Can you tell me what happened here?
Can you tell me what happened here?
ASKER
Removed the -d from the setfacl and it executed.
ASKER
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.
Try:
Try:
setfacl -m d:u::rwx,d:g::rwx,d:o::rwx directory_nameASKER
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?
# 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?
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.
ASKER
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.
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.
ASKER
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
[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
What makes you think that the files are readonly? Can you show what is read only?
ASKER
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.
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.
ASKER
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