Sticky Bit permissions

hi,
What's exact use of Sticky Bit permissions in unix .if oracle user does not have that permission wt will happen.

user1175505 wrote:
hi,
What's exact use of Sticky Bit permissions in unix .if oracle user does not have that permission wt will happen.Please ask your Linux questions in the Linux forum:
Oracle Linux

Similar Messages

Setting the sticky bit on a file fails in a zone

On initial inspection, the sticky bit on directories seem to be consistent across both the Global zone and local zone. However, they are inconsistent for files. Is this a bug, and if it is how to I raise a defect report?
Excerpt from chmod man page:
If a regular file is not executable and has {stick bit} set, the file is assumed to be a swap file. In this case, the system's page cache will not be used to hold the file's data. If the {stick bit} bit is set on any other file, the results are unspecified.
Solaris 10 update 4 (Global Zone).
# uname -a
SunOS mumble.amtest.com 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T1000
# chmod 1777 testfile
# ls -l testfile
-rwxrwxrwt 1 root other 0 Jul 11 14:24 testfile
# chmod 1770 testfile
# ls -l testfile
-rwxrwx--T 1 root other 0 Jul 11 14:24 testfile
# chmod 1000 testfile
# ls -l testfile
---------T 1 root other 0 Jul 11 14:24 testfile
Solaris 10 update 4 (Local Zone)
# uname -a
SunOS qatamos-z1 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T1000
# chmod 1777 testfile
# ls -l testfile
-rwxrwxrwx 1 root other 10 Jul 10 14:59 testfile
# chmod 1770 testfile
# ls -l testfile
-rwxrwx--- 1 root other 10 Jul 10 14:59 testfile
# chmod 1000 testfile
# ls -l testfile
---------- 1 root other 10 Jul 10 14:59 testfile

It isn't the fact that the bit isn't set. I guess the biggest complaint is that there is no error when trying to set the bit.
chmod returns success, even though it failed to set the bit.
Normally, if someone does not have enough privileges to modify permissions on a file, an error is returned.

Sticky Bit - Problem...

Hello,
I have one thing to ask, to clarify... Some weeks ago after a system migration from win/sql to linux/oracle (and after an oracle upgrade from 10.2.0.4 to 11.2.0.1), we faced an error during DB13, the job Scheduled Update Statistics finished with an error! After some research, we found the solution... the reason was the version of oracle instant client that was the version 10.2.0.2 (the first version of this OIC)!
So after I performed the update of oracle instant client (OIC) to version 10.2.0.4 (V3) the error finally disappeared... and it was the solution, which in that moment I thought it had been responsible for this correction!... but now I'm not so sure! Why?! Because the same problem appear again on another system, I performed the same solution, I updated the oracle instant client to version 10.2.0.4 v3 but unfortunately the problem still continue appear! So what I concluded, was that is not the solution, I realized this is not only because of the old OIC version that is installed in our system... there is other problem which is related to permissions!
Later I discovered that the STICKY BIT (?) had been applied before I have upgraded the oracle instant client... and in fact in this new system, after the solution of oracle client update the error still continued appear and in fact only after the application of sticky bit in this system the error definitely no longer appear!
So my question is what is this?... what is Sticky Bit?
I looked in SAP Marketplace if there were any related sapnotes to sticky bit but I didn´t found anything... this is some mandatory procedure?... if so, sap recommends the application of this where? in which situations?
I don´t know exactly what is STICKY bit and what he do... but the truth is that from the moment I applied it, with command ./saproot.sh (with root) on /sapmnt/SID/exe, we resolve the other part of this problem... I tried to search sapnotes in SAP marketplace about this sticky bit but I didn´t find anything... Can you explain me better if sap advice to apply this sticky bit... and if it can origin any problem or if there are any conflict with other things when we applied it on system!??
Kind regards,
Joao Dimas - Portugal

Now I think I understand the meaning and what is its functionality... but explain me another thing, the application of sticky bit with ./saproot.sh <SAPSID> changed other four files: brarchive; brbackup; brconnect and icmbnd (this five files now have a red colour)...
Yes, and they have an "s" instead of an "x" if you use ls -l.
The same thing is true for those files. The br*tools must be run as the user running/owning the database software (oraadm during startsap.
So, if this is so important to run (because if I didn´t ran this command the job throught DB13 can not runs) why there isn´t sap notes or sap documentation, discussing this issue and the need to apply the sticky bit to fix this problem?
It's documented - but hidden:
http://help.sap.com/saphelp_nw70ehp1/helpdata/en/43/3753c4b87b6025e10000000a422035/frameset.htm
Markus

Sticky bit in unsupported AUR packages

Hello,
In my ventures to provide a PKGBUILD for an app called gnump3d, I've come across something with the unsupported (only?) build script packages in AUR that can cause some problems.
Here is an (one) example of such a package:
$ wget --quiet aur.archlinux.org/packages/tomcat/tomcat.tar.gz
$ tar tvzf tomcat.tar.gz
drwxr-sr-x nobody/aur 0 2006-06-27 02:50:53 tomcat/
-rw-r--r-- nobody/aur 938 2006-06-27 02:49:10 tomcat/PKGBUILD
-rw-r--r-- nobody/aur 415 2005-06-16 20:11:45 tomcat/tomcat.conf.d
-rwxr-xr-x nobody/aur 706 2005-06-16 20:11:12 tomcat/tomcat
Notice the owner, group and the sticky bit on the directory. These permissions seem to be standard for the AUR build script packages.
Now, if use aurbuild to build this package, I get this content in the package:
drwxr-sr-x root/root 0 2006-08-08 01:48:05 etc/
drwxr-sr-x root/root 0 2006-08-08 01:48:05 etc/rc.d/
-rwxr-xr-x root/root 706 2006-08-08 01:48:05 etc/rc.d/tomcat
drwxr-sr-x root/root 0 2006-08-08 01:48:05 etc/conf.d/
-rw-r--r-- root/root 415 2006-08-08 01:48:05 etc/conf.d/tomcat
<SNIP>
I'm pretty sure that these sticky bits weren't intended. If I build the package with yaourt, which uses srcpac as a backend, things get more troublesome:
drwxr-sr-x root/549 0 2006-08-08 02:03:00 etc/
drwxr-sr-x root/549 0 2006-08-08 02:03:00 etc/rc.d/
-rwxr-xr-x root/549 706 2006-08-08 02:03:00 etc/rc.d/tomcat
drwxr-sr-x root/549 0 2006-08-08 02:03:00 etc/conf.d/
-rw-r--r-- root/549 415 2006-08-08 02:03:00 etc/conf.d/tomcat
<SNIP>
549 ought to be the group id of aur in the AUR repository.
Careless usage of makepkg can also make this happen. Not building as root, but in a fakeroot environment, seems to prevent it from happen.
From what I can see, the erroneous permissions are created when the install command is used in the PKGBUILD script, within the newly unpacked build script package.
This is certainly not meant to bash the authors of aurbuild or yaourt (or tomcat; many PKGBUILDs use install, mine included), I just wanted to raise the issue. Can something be done about this? Don't know where, though. Removing the sticky bit on the directory in the build script package would be one solution. Or maybe makepkg could warn about erroneous permissions. Or... Or something? Is it a bug or a feature?
Cheers

Ok fixed aurbuild. Now it extracts the tarball from AUR into /tmp then copies it into the build dir which inherets the modes and owenership of the parent directory there (being $HOME), I'm pretty sure this is how tar does it.
As pointed out above this setgid issue only occurred during root user builds.
More info:
-v1.5.1 (August 8, 2006)
*Fixed inhereted setgid bit in the built the package resulting from AUR's set mode of the parent directory in the tarball.
The unwanted inhereted bit occured only under the following circumstances:
- user was root.
- a 'install -m' line was excuted in the PKGBUILD without explicitly setting the first pair of octets, ie 644 instead of 0644
- Any other type of 'chmod' command without the first octet set.
If you have built any packages meeting the criteria list above, rebuild and install offending packages now. Run the update command to get the list of all
packages built from AUR. String them together in a space separated line to aurbuild and use the menu to see if any install/chmod lines were used. You can
use (s) from the menu to skip the current package and move on to the next.

Sticky bit, ACL, POSIX

Hi All,
After one day googling and testing (Snow Leopard Server 10.6.6) I didn't find any solution to what I thought to be a basic permission schema;
I need to set up just one share with read and write permissions for the group and delete permission for the owner; what I get is very close, but needs fine-tuning;
For example, user1 and user2 (belonging to group1) are able to create and delete their own files (and folders) in the share1, but user1 can't write in user2 folders and viceversa, and that's exactly what I miss;
I've spent a lot of time messing around with POSIX, ACL, sticky bit and a mix of them, but what I get is always more (users can delete each others' files) or less (they can't create files in each other's folders) than what I wanted…
users are in OD but the clients are just standard mac with local administrator accounts
Any assistance would be appreciated

First off you can't do this with POSIX permissions because both create a file and delete a file rely on the same permission (write permission on the directory), therefore if you're allowing someone to create a file you're allowing them to delete it, too.
You should be able to get there with ACLs, though.
Given the directory /path try:
chmod +a "group:staff allow list,add_file,search,add_subdirectory,readattr,writeattr,readextattr,writeextat tr,readsecurity,file_inherit,directory_inherit" /path
chmod +ai "group:staff allow file_inherit" /path
chmod +ai "group:staff allow add_file,add_subdirectory" /path
chmod +a "user:user1 allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,re adextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_i nherit"/path
These will allow any user in the staff group to create files and subdirectories in /path, and give user user1 the additional ability to delete files. The tricky part lies in getting the inheritence correct (the +ai switches) so that subdirectories inherit the permissions of the parent (which is what allows user1 to delete files in a subdirectory created/owned by a different user.

Sticky bit and chattr

I want to protect my folders in $HOME from an accidental deletion. I applied chattr +i on them but i noticed that the last is applied recursively, thus, indeed the folder can't be deleted but also i can't write in it.
I also tried to apply a sticky bit with chmod 1775 and change the ownership of the folder with chown root foldername. Normally, with sticky bit enabled, only the owner of the folder can delete it but, strangely, in my case although the folder is owned by root, i can delete it with my normal user.
I noticed that the users folders in /home partition, although they are owned by the current user and have rwx permissions for the owner, they can't be deleted/changed. How is this achieved?

It would require sticky bit to be set to every subfolder in /home. sticky bit isn't applied recursively by default. If you're worried about deleting your own files by accident it seems to me a better solution would be a daily incremental backup using something like rdiff-backup.

UIS GID and sticky bit problem

Not sure the best place to post this, could not find a forum that really matched what I am asking.
My Chronosync is having problems with not being able to backup certain files. (cover.jpg)
I seem to have traced it to files with what I think is a Sticky bit....but I thought a file with a sticky bit was shown with a t as in:
-rwxrwxrwxt
but the problem files are shown :
-rwxrwxrwx@
It is a file that I have moved from one user to another via the Drop box...so i know that causes issues with UID GID and Sticky bits etc
How in terminal do i correct the file permissions to:
-rwxrwxrwx
OK I could just re download the file or copy it from the other user another way...but I am still interested in this "@" attached to the permission string and how to change it.
have tried various combinations of chown and chmod but cant get any change...
I have seen some references to it being a indicator to the OS that it is a file downloaded from the internet...but how to remove this ?
sh-3.2# ls -l
total 1986808
-rwxrwxrwx@ 1 bonair staff 6148 3 May 13:45 .DS_Store
-rwxrwxrwx 1 bonair staff 174187271 3 May 14:11 01 - Bastity Chelt.flac
-rwxrwxrwx 1 bonair staff 144769872 3 May 14:11 02 - Jersey.flac
-rwxrwxrwx 1 bonair staff 179664537 3 May 14:11 03 - The Football Match.flac
-rwxrwxrwx 1 bonair staff 133005983 3 May 14:11 04 - America.flac
-rwxrwxrwx 1 bonair staff 38122932 3 May 14:11 05 - Zits.flac
-rwxrwxrwx 1 bonair staff 54626233 3 May 14:11 06 - Number Plates.flac
-rwxrwxrwx 1 bonair staff 129378885 3 May 14:11 07 - The Bus Trip.flac
-rwxrwxrwx 1 bonair staff 57536059 3 May 14:11 08 - Car Insurance.flac
-rwxrwxrwx 1 bonair staff 104705018 3 May 14:11 09 - Magic Roundabout.flac
-rwxrwxrwx@ 1 bonair staff 471848 3 May 12:04 cover copy.jpg
-rwxrwxrwx@ 1 bonair staff 471848 3 May 12:04 cover.jpg
sh-3.2#

I already gave you the Unix command to tell you what the @ indicates
ls -aleO@ # lowercase l, lowercase e, capital O, and at sign
Why not use it?
I also suggested what each extended attribute might be, but without output from the above ls -leO@ I can only guess.
Here are the relevant parts of "man ls"
-a Include directory entries whose names begin with a dot (.).
-l (The lowercase letter ``ell''.) List in long format. (See
below.) If the output is to a terminal, a total sum for all the
file sizes is output on a line before the long listing.
-e Print the Access Control List (ACL) associated with the file, if
present. Also see "man chmod".
-O Include the file flags in a long (-l) output.
Also see "man chflags".
-@ Display extended attribute keys and sizes.
There is no man page for extended attributes, however, there is a minimal amount of usage information built into the command:
xattr --help
usage: xattr [-l] file [file ...]
xattr -p [-l] attr_name file [file ...]
xattr -w attr_name attr_value file [file ...]
xattr -d attr_name file [file ...]
The first form lists the names of all xattrs on the given file(s).
The second form (-p) prints the value of the xattr attr_name.
The third form (-w) sets the value of the xattr attr_name to attr_value.
The fourth form (-d) deletes the xattr attr_name.
options:
-h: print this help
-l: print long format (attr_name: attr_value)

Sticky bit changes the value of the script parameter 0

Hi,
I have a simple shell script:
#!/bin/sh
echo $0It simply returns its own name.
But when I set a sticky bit on this script, it returns
/dev/fd/3
Is it like it is supposed to be? What is the rationale behind such behavior?
I use Solaris 8.
Thanks,
Yevgeny

I have a simple shell script:
#!/bin/sh
echo $0It simply returns its own name.
But when I set a sticky bit on this script, it
returns
/dev/fd/3s/sticky/setuid/
or
s/sticky/setgid/
Is it like it is supposed to be?Yes
What is the rationale behind such behavior?If fixes a race condition for setuid / setgid "#!" interpreter scripts.
Without it, someone could replace the script file during the small
window between the kernel's exec of the interpreter /bin/sh and
the time the /bin/sh shell opens the script.
The fix is to pass a reference to the already open script file using
the /dev/fd/N pseudo filesystem.

Another iAS6 SP4 ? - sticky bits on, 5 kjs's, yet all activity routes thru 1 kjs

Although StickyLB set, check marks did not show thru admin tool. Once app server was bounced, all activity was balanced (viewed via OS threads) and StickyLB showed checked thru one instance of admin tool. Other such happenings elsewhere?

Tom:
What kind of application are you using, Servlet or JSP or else?
Alex

Solved: pacman - permissions differ on tmp/

Not sure if anyone else is seeing this because this may have been part of something I did a way back. I'm getting:
( 35/400) upgrading filesystem [######################] 100%
warning: directory permissions differ on tmp/
filesystem: 777 package: 1777
I know a bit about the filesystem package. If I remember correctly it contains files that are Arch specific like the boot scripts... Now if I'm reading this correctly the 777 permissions of "filesystem" is original directory and "package" is the package's permissions for the tmp directory. Here's my /tmp directory permissions after the update:
drwxrwxrwt 11 root root 4.0K Sep 13 11:41 tmp
Can anyone help me clarify this? Is the problem now fixed, or is there something I need to do?
Last edited by Gen2ly (2010-09-13 19:49:14)

I haven't seen pacman changing permission on directories yet, but according to the message, your /tmp didn't have the sticky bit set before the upgrade. Though things will work fine with just 777, not having the sticky bit on /tmp will mean that someone could delete and replace files owned by someone else, which is a security risk.

Permz - Quickly change file permissions in any file manager

Designed to be integrated into any file manager, permz is a bash script which presents a GUI menu. You can use it to quickly change file permissions and ownership as a normal user or as root, and delete files as root. I wrote this because I have yet to see a file manager that isn't cumbersome for this - the mechanism is usually buried on a second tab of the Properties window, and changing permissions often involves multiple clicks in a grid. To change the owner of a file, you need to type the username. And if the file is owned by root, you can't do anything.
permz --help
Presents a GUI menu for changing file permissions/ownership. May be run
as a normal user or root.
Requires: zenity gksu
Optional: sudo (recommended to prevent multiple root password prompts)
Usage: permz FILE [...]
MENU FUNCTIONS:
rwxrwxrwx Sets file(s) to given permissions
Sticky Clear/Set Performs "chmod -t" or +t to clear or set the sticky
bit. You may select to clear/set sticky in addition
to changing other permissions.
Recursive go-rxw "chmod -R go-rxw" on file(s) recursively, denying
access to non-owners
Recursive go-w "chmod -R go-w" on file(s) recursively, denying write
to non-owners
Recursive ugo+rX "chmod -R ugo+rX" giving read access to all. Also
sets +x for directories and executables.
Recursive ugo+w "chmod -R ugo+w" on file(s), giving write to all
(You may select several compatible recursive functions above at once)
Owner USER As ROOT Sets ownership to USER:USER as root
DELETE As ROOT Deletes file(s) as root. Must be used alone or with
"Perform Recursively" (to delete directories - USE
WITH CAUTION). Not available if permz is run as root.
Perform As ROOT Run as root to change selected permissions.
(Use of root is automatic when changing ownership)
Perform Recursively Adds -R to all chmod, chown, and delete commands to
descend into subdirectories. Use in conjunction with
any other functions. (Recursion is automatic for
"Recursive" functions above)
Current su command is set to: gksu -gS
If you're somewhat familiar with bash, adding additional options or changing the existing ones is straightforward.
I have tested it pretty thoroughly but if you do encounter anything amiss please let me know.
More details at http://igurublog.wordpress.com/downloads/script-permz/
And in the AUR at http://aur.archlinux.org/packages.php?ID=36978
Instructions for integrating permz into PCManFM-Mod are here.
Last edited by IgnorantGuru (2010-05-05 13:53:08)

rransom wrote:Recursive ugo+rX would be more useful than "Recursive ugo+r (dirs +x)". (The +X feature of chmod is available at least in GNU coreutils, FreeBSD, and POSIX 2003.)
Done - thanks for the tip. I also left the old code active in there with just the menu option disabled, so if anyone wants it the other way or wants both it's easy to enable. The difference is that the old way won't make any files +x, just dirs.
permz doesn't provide every possible setting of permissions, just common ones, so you may want to customize it. But I used to have these as user actions when I used Krusader and I found these were the handy ones, at least for me.

File Permissions in Solaris 10

Hi,
I have a problem with permissions on a shell script file. Although the file permissions are "-rwxrwxr-x" anyone else in the group, apart from file owner can't execute this file.
Regards,

First of all thanks for trying to help me. The command line output for:
--> "+ls -al /tmp/restart.sh+" is "+-rwxrwxr-x 1 admin1 admin ...+"
--> "+ls -ald /tmp+" is "+drwxrwxrwt 13 root sys ...+".
When anyone else in the admin group, besides the owner of the file, try to execute that file they get the following error: "+error: chmod: warning: can't change /tmp/restart.sh+".
If I change file owner it works properly, but I don't want to change the owner each time the file is used. Maybe it's all about that sticky bit?!
Best regards,

GDM update: directory permissions differ on /var/log/gdm/

Hello,
Running Arch 64Bits kernel 3.9.9-1 with systemd and i got the following warning during a gdm update today:
(1/6) upgrading libgdm [######################] 100%
(2/6) upgrading gdm [######################] 100%
warning: directory permissions differ on /var/log/gdm/
filesystem: 711 package: 1770
Why would gdm need some 1770 permissions for log files? Looks pretty suspicious to me, especially the sticky bit thing. What did i miss?
PS: BTW the update is successful (it's a warning afterall, not an error)
Thanks
EDIT:
Looks like the opposite situation than 3 years ago:
https://bbs.archlinux.org/viewtopic.php?id=94681
https://bugs.archlinux.org/task/19294
EDIT2: here's what i have in /var/log:
msytux666 var # ls -la
total 64
drwxr-xr-x 14 root root 4096 Jul 6 15:34 .
drwxr-xr-x 20 root root 4096 Jul 16 20:24 ..
-rwxrwxrwx 1 root root 4192 Jun 19 11:27 .com.zerog.registry.xml
drwxr-xr-x 7 root root 4096 Jul 7 00:07 abs
drwxr-xr-x 8 root root 4096 Jun 16 17:28 cache
drwxr-xr-x 3 root root 4096 Jun 17 19:07 db
drwxr-xr-x 2 root root 4096 May 31 20:40 empty
drwxrwxr-x 2 root games 4096 May 31 20:40 games
drwx--x--x 2 gdm gdm 4096 Jun 15 14:23 gdm
drwxr-xr-x 26 root root 4096 Jul 16 01:13 lib
drwxr-xr-x 2 root root 4096 May 31 20:40 local
lrwxrwxrwx 1 root root 11 May 31 20:40 lock -> ../run/lock
drwxr-xr-x 6 root root 4096 Jul 18 00:33 log
lrwxrwxrwx 1 root root 10 May 31 20:40 mail -> spool/mail
drwxr-xr-x 2 root root 4096 May 31 20:40 opt
lrwxrwxrwx 1 root root 6 May 31 20:40 run -> ../run
drwxr-xr-x 6 root root 4096 Jun 16 17:28 spool
drwxrwxrwt 8 root root 4096 Jul 18 00:33 tmp
gdm is owned by gdm, so why would it needs 1770 permissions?
EDIT3:
After further research i appear the way gdm is installed may matter.
Well i installed gdm through pacman and always update it with pacman as well. Never manually compiled/make_install'd it nor used abs for it.
Last edited by BGK (2013-07-19 21:37:13)

Okay I'm confused ...
Commit:https://projects.archlinux.org/svntogit … 92c38d536d
@@ -68,8 +68,7 @@ package_gdm() {
cd $pkgbase-$pkgver
make DESTDIR="$pkgdir" install
- chmod 1770 "$pkgdir/var/log/gdm"
- chmod 700 "$pkgdir/var/lib/gdm/.config/dconf"
+ chmod 711 "$pkgdir/var/log/gdm"
rm -r "$pkgdir/var/run" "$pkgdir/var/gdm"
### Split libgdm
so that takes away the 1770 permissions, and replaces them with 711.
@@ -5,6 +5,7 @@ post_install() {
getent passwd gdm > /dev/null 2>&1 || usr/sbin/useradd -c 'Gnome Display Manager' -u 120 -g gdm -d /var/lib/gdm -s /sbin/nologin gdm
passwd -l gdm > /dev/null
chown -R gdm:gdm /var/lib/gdm > /dev/null
+ chown root:gdm /var/log/gdm > /dev/null
glib-compile-schemas /usr/share/glib-2.0/schemas
gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
however:
chown root:gdm /var/log/gdm > /dev/null
.. is where I get confused. This command makes root and the group gdm the new owners of /var/log/gdm, or did I go wrong somewhere?

Permissions Mysteriously Changed

I regularly access my second hard drive (internal) but, suddenly today the permissions have changed. I have no idea why. What's worse is that I can't change them back. Under all categories, it is now on "custom". When I try to change them, it goes straight back to "custom". The icon of the second HD has a lock on it now and when I try to open it, I am told that I don't have sufficient access privileges.
I don't understand how this could possible happen. I have made no major changes to anything and nobody has been in my home to hack my computer.
Can anyone help?
Mark.

Glad things are working again!
A further caveat if you did an Archive and Install rather than an Erase and Install - When you clicked "Apply to Enclosed Items" it presumably affected everything on the HD, and as I had mentioned earlier, an Archive and Install, preserving Users, might not fix the ownership and permissions on your Home folder and its contents. Disk Utility's Repair Disk Permissions won't fix a Home folder either. The startup volume was owned by System; your user account should own everything in your Home folder. A further wrinkle, which pushes my limited knowledge of Unix, is that the permissions on the startup volume include a set "sticky bit", and this might also have gotten transmitted everywhere else, leading to potential problems when deleting things.
I would do a Get Info now on your Home folder and on a few of your files and folders within it, and make sure you are listed at the top of the permissions list, with read-write privileges. "System" should not appear there. If there does seem to be a problem with the ownership and permissions of your home folder, [this post by V.K.|http://discussions.apple.com/thread.jspa?messageID=10885473&#10885473] in the thread I had listed earlier describes how to fix it.

[SOLVED] Different delete permissions on one folder

My friends ask me to run a server for our small neighborhood, for purposes like files share and things like that.
I learned Here that the user permission to delete any file is inherited only from the "father" folder.
As for the files share, I would like that each user will be able to upload his own files, and while any user will be able to read and download any file (read permission only),
only the owner user will have the ability to delete his own files.
At the moment there is main folder with 777 permissions for everyone, and within it each user opened his own directory.
This way when some files exist in the folder of another user you cannot delete his folder/files.
But this is bad for sorting needs, I want that any user who provide installation file will be able to put it in the "Installations" folder...
Most of the users are using ms-smb client to manage their files through my Samba server, and like that when one attempts to delete another-user's file from the main-full-permissions-for-everyone folder he even not receive that Linux warning: "remove write-protected file ‘file_name’? y"
Is there a way to do that on one directory?
I tried to learn about the ext filesystem "flags" just to find some flag to make the file delete-able only by the root, that not a solution.
Sorry for my bad English, not my native language...
Last edited by Florax (2013-01-27 11:29:14)

Thank you all very much,
I will read that all when I'll got the time, but for my purpose the Sticky Bit thing is very much enough.
Since I think it is very useful for multi-user use of the system, why there is not some simple Arch-Wiki about it?
Or maybe there is, but I am no good in searching?

Sticky Bit permissions

Similar Messages

Maybe you are looking for