![]() When a worker creates something in their own directory, we want other workers of the same sub-project to be able to read that new thing, but not modify it by accident. The idea is that content within /asic and /200T can be seen by all personell working on asic and 200T yet they cannot have write access to these 2 directories- if they want to create something, they'll have to do that within their own directories ( /lbh and the like). asic and /200T are owned by root and belongs to groups asic and 200T respectively, while /lbh is owned by the worker's user account lbh and belongs to group asic. asic, /200T, /lbh were all created by root and then had their properties reconfigured by root via chmod -R and chown -R. To set this permanently, use tune2fs -o acl or edit /etc/fstab./asic is our grand project's folder, /200T is a subproject of that grand project, and folders right under /200T such as /lbh are each worker's personal directories who are working on the subproject. Note: On older systems using ext3/ext4, you used to need to mount the filesystem with the acl option, otherwise it would ignore all ACLs and disallow setting new ones. (If needed, you can add a u:someuser:rwX or g:someuser:rwX – preferably a group – to the ACLs.) (Uppercase X means only directories will receive the +x bit.) This will apply setfacl to the /path/to/parent directory, -modifying the -default ACLs – those that will be applied to newly created items. Set the default ACL on a directory: setfacl -d -m u::rwX,g::rwX,o::- /path/to/parent However, you can use POSIX ACLs to achieve this. POSIX file permissions are not inherited they are given by the creating process and combined with its current umask value. Now, all new files and folder created under /path/to/parent will have the same group assigned as is set on /path/to/parent. The group ownership can be inherited by new files and folders created in your folder /path/to/parent by setting the setgid bit using chmod g+s like this: chmod g+s /path/to/parent The permission bits you are looking for are 07. ![]() You can remove permissions using '-' rather than '+'. You can also have 'u' for 'user' & 'g' for 'group', as well as 'r' & 'x' which are hopefully self explanatory. ![]() The 'o' means 'other' & 'w' means 'write'. Something you may like to try is: chmod o+w file (though resetting it to 660 may not be the worst of ideas.) You should change permissions as required. I would not chmod -R the entire directory because you don't want html scripts or jpg's or random other things executable. (Something like usermod -aG apache username) You can then do something like or even add yourself to the apache group to ensure you have group access to the directory. This will probably be either apache or httpd depending on your distribution.Į.g. I would suggest leaving the directory owned by the apache user/group. Grawity gives an excellent answer but I suspect the edited question may have changed things slightly. Files and folders in /path/to/parent is NOT world readable.files are read/writeable by user myself and members of somegroup. ![]() Directories placed under /path/to/parent are eXecutable by users with permissions.Can someone help please?Īctually the octal flag 660 is probably not even correct. However, everything I have tried so far has failed. Thereafter, I want the 660 permissions to be set recursively to any folders and files placed in /path/to/parent. Sudo chmod -R 660 myself:somegroup /path/to/parent This is what I have done so far: sudo mkdir -p /path/to/parent I know this involves setting a sticky bit, but I can't seem to find a command that shows exactly what I need. I want to maintain the user and group permissions recursively for all new folders and files placed in the parent directory. I have a folder in which new subfolders and files will be created automatically, by a script.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |