AFP inherit perms directories inherit owner!

I have a bunch of users who use AFP to access a communal volume on Panther Server 10.3.8. We were having problems with files being created by default rw-r--r-- so that only the owners could write them. In order to get round this I've turned on 'inherit permissions' on the server.
This works great for files - when a new file is created the owner is set to be the person creating, but the group and the permissions are inherited from the enclosing directory (which is set to be group writeable).
The problem I have is that when new directories (as opposed to new files) are created they seem to be set so that the owner is the same as the enclosing directory (unlike with files). This means that if a user creates a new directory they are unable to change permissions on the directory as they are not the owner - in particular the group cannot be changed. This makes it impossible for them to create a directory with a different group to the enclosing directory.
Why does creating directories behave different to files with AFP inherit permissions? Is there a way to change this? For my purposes it makes AFP inherit permissions next to useless.
Justin Powell
xserve g5 Mac OS X (10.3.8)

Unless I have missed something - leaving room for a mistake here - I would recommend people NOT upgrade from 10.3.9 server to Tiger server based on our ACL permission problems. If I had read this somewhere, I would have not upgraded. I was also told this "bug" we so enjoy would not be fixed until Leopard is released - circa Oct 2007.
I spent the night Thursday redoing the Tiger server install - from the ground up. Hand coded all users and only used the builtin staff group.
Using all the available tips I proceeded to:
1) turn on ACL for volumes.
2) reboot
3) set POSIX owner to "diradmin" (open directory owner) for all points that will be shared read write
4) set POSIX group ownership to "staff" read write
5) set POSIX everyone to read write
6) dragged staff group into ACL and set to full control
7) propagated each point
8) rebooted
9) enabled sharepoints
10) rebooted
a few hours later I am receiving calls from staff members that are creating documents that can't make changes to their new documents. Of course I am at home asleep because I was up for 24 hours before I went home. Had I been awake, I would be assured I was living a nightmare which really began a few weeks ago, the day we decided to finally use our Tiger server installer.
The most valuable tip I ran across is very poorly highlighted, the fact that you CANNOT propagate root owned files and folders. We all know that root/system owned files and folders are the ideal server side rights. What in the freaking world would posess anyone to change that??????? and not provide adaquate warning. So I will reiterate here because many people are missing this crucial point.
YOU CANNOT PROPAGATE ROOT/SYSTEM OWNED FILES AND FOLDERS PERMISSIONS
Even if you could, you are not guarenteed that ACLs will work. They simply don't work at all here - bug!
No, I'm not erasing 11 terabytes of storage to see if that helps. It didn't work on the internal 200 gb drives.
sincerely, Bugie
XServe G4

Similar Messages

Inherit Permissions option not showing up for AFP shares

Hello,
I am running OS X Server 10.5.8, and I recently noticed that the option to inherit permissions from parent is not showing up under protocol options. I used to see Default permissions for new files and folders, and now that section does not show up.
I have searched around and seen one other post where someone had a similar issue, but the post was not answered.
Thanks,
Scott

Thanks for the response. I tried the terminal command, and it went through without an error, but inherit permissions are still not working. I tested saving file to this volume and it did not inherit the permissions set through Server Admin.
When I launch server admin, I don't even see the option to configure Inherit Permissions. Is there a global setting somewhere?

Inherit Permissions from parent

If I were to use Inherit permissions from parent instead of standard POSIX on a share, what happens
when you propergate permissions? Do permissions that you explicitly set get changed by the parent folder?
Are there any issues I should be aware of before trying Inheritted permissions?
The reason I want to change is because I have folders on my RAID that for instance hold raw un-touched images, whoever saves the files into this folder becomes the owner and everyone is read only, which is no good if someone else wants to make changes and save over the image, I have ACL set to try and overcome this, but Photoshop doesn't respect ACL and just goes by the POSIX permissions. Which means users are having to save to desktop and the drop the file in the raw image folder to replace it - which is ok but not perfect.
If I were using Inherit permissions and set the raw folder to everyone read and write, then in theory any files added into the folder would be read and write for everyone, is this correct? if so, what would happen to the permissions when a second user edits the image and re-saves it, is it still inheritting the read write permissions?
Hope this makes sense and i'm not rambling too much, but with 3Tb of files on the RAID I can't afford to experiment and screw up the permissions on the existing files else I'll be killed by 10 angry designers!

Did you ever find an answer to this? I'm having the same problem and wondering if it's simply a 10.5 server glitch. You shouldn't have to use ACL to get around it and as far as I know, if you set POSIX to inherit permissions from parents, that's exactly what should happen. But it doesn't for me either. Whoever creates a folder on our RAID becomes the new owner and staff is read-only.

Inherit Permissions - Odd behavior-need explanation

I am a site/subsite owner with no rights at the site collection level. While creating a new subsite, I accidently removed most groups from site permissions for the top level site I control. As sometimes happens, rather than taking a few minutes
to breathe, I thought to reverse my mistake by clicking on the Inherit Permissions button on the top level I own. The permissions were then the same as the site collection level.
Below my top level site, called "TOP", I have 10 subsites which had unique permissions. Inheritance has long been broken from TOP and there are also hundreds of unique library and list group assignments (these were not inheriting either).
When I clicked that button on TOP, not only did TOP revert to collection permissions, every subsite, every library and list, reverted to the permissions granted at the site collection level as well except for 2 subsites where I did not have access. (lots
of repair work to be done now) 3 custom permission levels, 2 of which I did NOT create, disappeared.
My understanding of breaking inheritance is that once broken, changes made above the break will not flow down. I would think that clicking on Inherit Permissions on the site above the break would have the same effect. The reversion would stop where inheritance
was already broken.
Is my understanding incorrect or did we have some type of issue behind the scenes that caused this to happen?
Thanks!

Fadi,
I'm not sure if your "yes" means I am incorrect or that we have something corrupted.
I would like to add that along with the complete re-inherit and permissions removal waterfall effect throughout the multiple subsites, libraries and lists, custom permission levels were deleted. We had 3 custom permission levels, 2 of which the farm
administrator had done and 1 of which was done by me. When I discovered they were gone, I went to add them back and found that my top level site was locked in an inherit state for permission levels and was not able to add or change any levels. Nor can
the farm administrator.
Anyone else who could contribute to this thread? We're trying to find root cause and I'd like to get a definitive statement as to whether or not selecting Inherit Permissions from the top site level should cause all subsites/lists/libraries/bascially
everything with unique permissions up to 6 layers down to inherit from the site collection again.
Thanks for your input!!!
marilou Borries

"Inherit Permissions From Parent" doesn't work

In OS X 10.5 server, selecting the option for an AFP share to inherit permissions from its parent does not work for users on OS X 10.3. All files created by users running 10.3 have 755 permissions, regardless of the parent folders permissions.
Clearly, this rather dramatically reduces the utility of AFP in 10.5 Server for anyone with users running OS X 10.3.
OS X 10.3 server did not have this problem.
Manually propagating permissions is futile for two reasons. First, the needed set of nested permissions is complex enough that propagating them manually would take hours, and secondly there would be intervals between the propagations when documents would not be accessible to the right people.
Consider a drastically simplified example:
Imagine a share named "Share" with a folders inside it named Admin. Inside the Admin folder might be two additional folders named Accounting and Personnel. Inside Personnel there are folders named Performance Review and Forms. It would look like this:
Share
-- Admin
----- Accounting
----- Personnel
-------- Performance Review
-------- Forms
Now consider several groups: Employees, Accounting, HumanResources
Employees should have read write access to Share, and everything under it unless more restrictive permissions are explicitly created. Only the Accounting group has access to Accounting, and everything in Accounting should only be accessible to Accounting. Performance Reviews should only be accessible to the HumanResources group, but Forms should be accessible to all Employees.
Now a member of the employees group saves a new file in the Forms folder, but the group doesn't have, and needs, read/write privileges. To fix this the permissions from Share can't be propagated to all the files and folders inside it because that would nuke the special privileges for Performance Reviews and Accounting.
It might be conceivable that every n minutes a script could run that would recurse, depth first postorder, through the hierarchy assigning all files in each folder the permissions of the enclosing folder, but there are at least two problems with that. First, it would be slow and between runs the files wouldn't have the right permissions. Second, sometimes we might want a file to have special explicitly specified permissions that differ from the parent, but it would be terribly cumbersome to specify the exceptions for this sort of script.
POSIX behavior also doesn't solve the problem because it will set the same permissions as we're seeing already, there's no obvious way to change the default permissions, and doing so would have security implications elsewhere on the server if that "umask"ish setting couldn't be specified exclusively for the share.
Inherited permissions would solve the problem, and have solved the problem under past versions of OS X server, but they don't work on 10.5 with 10.3 clients.
Does anyone know of a workaround or have any additional details?

glad someone else is experiencing this, I'm having the same problem with inherit from parent.
I was going to start using inherit because Leopard has ruined ACL's, Leopard clients don't honour the deny delete subfolders and files ACE, basically the leopard permissions systems seem to be flawed

Set user inherit permissions check box using powershell

Hi All,
How can I set the the "include inherit permissions from this objects parent" propertiy in Active Directory user object to a list of users using powershell.
This option is not checked for some of my users and I'll like to set it using a powershell script.
Thanks
Simon
MCSA, MCSE, MCITP:SA, MCITP:EA, MCITP:Enterprise Messaging Administrator 2010, CCNA

download Quest Active Directory:
Get-QADUser -SizeLimit 0 | ? {$_.DirectoryEntry.ObjectSecurity.AreAccessRulesProtected} | Set-QADObjectSecurity -UnLockInheritance
or
Get-QADUser -SizeLimit 0 | ? {$_.security.PermissionInheritanceLocked} | Set-QADObjectSecurity -UnlockInheritance
or
$user = [ADSI]"LDAP://cn=kazun,ou=test,dc=contoso,dc=com"
$acl = $ouser.objectSecurity
$isProtected = $false # allows inheritance
$preserveInheritance = $true # preserve inherited rules
$acl.SetAccessRuleProtection($isProtected, $preserveInheritance)
$user.commitchanges()
I had this issue and using both of Kazun's methods worked. A mod should mark this as the answer.Paul Frankovich

Document library not automatically inherit permissions from parent

Hi all,
Whenever I create a new document library the inherit permissions not automatically set for this library, So I have to click Inherit permissions for each time i create a new document library. please
help to apply inherit permissions automatically whenever new library create.
Manikandan

Hi Alex,
when you create a library and then go to the permissions settings for it it's set to not inherit permissions?
Ans : It Does not have any inherited permissions from the parent site.
Does it have a copy of the standard permissions set? If not what does it have and what is it missing from the site default?
Ans : No. Empty permissions.
But whenever i stop and start apply inherited permissions on the parent site works fine (I mean apply to all document library). but i could not do it all time whenever the new library create. I hope whenever the permissions changes on the parent site may
affect the document lib permissions. pls help how to proceed ?
Manikandan

Inherit Permissions without server purchase

The issue of not being able to allow me to enable a folder to inherit permissions is a problem. all mac os previous to X would let me do that. Even all windows os will let me do that. I've heard it's for improved security but at this point I would rather have flexibility than security. Since this is the only feature that I need that is on the $499 os x server I don't want to purchase that server for that one little feature that is common in windows and past mac operating systems.I hope future os upgrades will restore this option. Thank You
If anyone knows of a workaround or shareware app that would help. that would be great. Thanks

Supposedly this can be done in the CLI using chmod. There's no way to do it in the Finder. I've played around with chmod on this, but haven't had much success yet. I'm still researching it myself.
Does anyone have any better suggestions? Thus far, I'm having trouble finding out exactly how to write the chmod line to do this.
Exactly what I'm dealing with is an OS X 10.5 client machine (NOT a server) on which I want to set up a shared folder. It's a graphics folder on an Active Directory domain. What's happening is when different users modify files in that folder, the permissions get all out of whack, and some people can make edits to some files when others can't. I have to keep going in and have permissions from the root folder inherit down, but that only works that once. I need it set to continually inherit from that root folder so that a particular ground defined in Active Directory will always have read/write access to the files and folders contained within.
I've also read something that said that OS X doesn't support dynamic inheritance, meaning that even if I sets up inheritance on a folder, it only applies to a folder or file is created; but if I change the permissions on the root folder, it won't change anything that currently exists in the files/folders below it. Is this true?
- John

Inherit permissions

Hi all, does someone know how to get a folder or file to automatically inherit the server permissions after being copied over?
I have mac os 10.6.8 server, and only macs in the network.
thanks for any tips.

You must use ACLs. POSIX inheritance was dropped after 10.4. If you have a folder with existing content, then after applying the ACLs to the root folder (the shared folder), you must propogate permissions. This function is available under the Gear icon menu.

Can I set new shared folders to inherit permissions from the parent folder?

Am running file sharing on an OS 10.9.5 machine. This is not an OS-X Server.
9 users connect to this machine. They create folders and store files on it. All the users who connect are in a group which has read and write permissions on the volume in which they store files. But when they create new folders, the permissions on the new folder is 755. I have changed the umask to 002 and this works for users who might create a folder locally but does not work for network connected users. All users are AFP and, if it matters, are on 10.8.5. The OS versions are held back for good reason.
Is there a way to enable Inherited Permissions for new network created folders on the standard client OS?
If not, can I do so on the server OS? I have several older OS-X Server machines where this is a possibility.
(Sorry if this is a duplicate but most posts like this seem to concern locally created files and folders and not network shared folders.)

It can be done more easily with OS X Server, but you can do it anyway if you're familiar with the shell. See the section headed "ACL MANIPULATION OPTIONS" in the chmod(1) man page.

How do you get a new file in a shared folder to inherit permissions

I have a shared folder that I share with a co-worker and having trouble with the permissions for new files/folders.
When he creates a new file or new folder, the permissions for that file/folder are set as read only for myself. The parent shared folder is set at "Read/Write" for both of us.
Is it possible to control the permissions for new files/folders?

Actually, that property used to go in the entry for that sharepoint in the "NetInfo" database, and really only worked properly when 'afpuse_parentowner' was also set. The .plist file controls the behaviour of the afp server as a whole, not that of individual share points.
I'm not sure what the "DirectoryService" equivalent is - a lot of the things have similar names but differ in "case", but some things are completely different or absent.
Unfortunately, I'm not equipped to test these things myself but changes can be made using 'dscl', or possibly by editing the flat files directly in a manner similar to what is described here:
http://www.macgeekery.com/hacks/software/netinfo_dead

File Sharing - inherit permissions of parent folder

First off, let me say that I'm a UNIX guy so I like the command line. The server admin tool is pretty unfamiliar territory for me..
A friend of mine runs a graphics design firm and he needed a server. I set him up with an Xserve and let me say that it is blazing fast. I am having a problem though..
There are currently two computers on the network, we'll call them users Mark and Jim. If Jim creates a file on the share, then Mark can't modify it and vise versa. This is obviously a permissions issue. Seen it a million times. Now...
the permissions that are carrying over from the workstations are rw-r--r--. I'd like everyone to be able to modify these files on the share.
The share is set up as permission 755 and if a new file/folder is created, I'd like it to pick up these permissions.
I'm confused by this AFS/ACL/ACE vs. POSIX thing. Can someone help me out here?
I had a UNIX server running NFS previously and never saw this problem.

Hi
For a good explanation and understanding of how ACLs work:
http://discussions.apple.com/thread.jspa?messageID=1535247
The above is for 10.4 Server. For 10.5 Server:
http://discussions.apple.com/thread.jspa?threadID=1234220&tstart=0
If you look here:
http://discussions.apple.com/forum.jspa?forumID=1233
You'll notice a lot of discussions regarding file sharing (the forum itself) and permissions (ACLs, POSIX) problems in particular. These current threads:
http://discussions.apple.com/thread.jspa?threadID=1251475&tstart=15
http://discussions.apple.com/thread.jspa?threadID=1428118&tstart=15
may provide more information. There is also some discussion regarding the SMB service itself. In 10.5 it appears to be not fully functioning as it should. It seems access for clients is achievable only if Guest Access is enabled which kind of defeats the whole notion of controlling access. Apple may be addressing these issues in a forthcoming update? You could perhaps research this further? There are numerous online resources available that may be useful:
http://www.apple.com/server/macosx/resources/
http://www.afp548.com/
http://bombich.com/
http://www.macosxtips.co.uk/
Hope this helps, Tony

Stumped on AFP network home directories.

Heyo,
Been RTFMs on File Services, User Management and Open Directory. Also looked in www.AFP548.com but didn't find anything helpful.
We have a mixed environment and windows users aren't having any problem with network domain logins or using smb shares. Mac clients can mount the network shares with afp but network homes are a no go.
Made the changes needed for the firewall and tried it with the firewall off just to be sure.
The /Home share is automounted (not using the default /Users).
Guest access is on in Sharing and AFP.
Network Mount for /Home is set to Enable network mounting, AFP and User Home Directories.
SMB Windows Homes are in the same directory and run without problems.
Directory Access on the Client saw the server and looks ok.
Only ref. I can find for the login attempt is under Open Directory Password Service Server Log:
Apr 23 2006 16:42:31 RSAVALIDATE: success.
Apr 23 2006 16:42:31 USER: {0x00000000000000000000000000000001, netadmin} is the current user.
Apr 23 2006 16:42:31 AUTH2: {0x00000000000000000000000000000001, netadmin} CRAM-MD5 authentication succeeded.
Apr 23 2006 16:42:31 QUIT: {0x00000000000000000000000000000001, netadmin} disconnected.
and OD LDAP log:
Apr 23 16:42:31 ci slapd[81]: bind: invalid dn (netadmin)\n
Nothing in the AFP log.
Any thoughts on what I should try or something obscure I may have missed when setting up MacOS client network home directories with AFP?
Thanks
Mitch
Server: 10.4.6
Workstations: 10.4.6

Getting closer.
Kerberos wasn't running and the ODM wouldn't Kerberize.
This thread sorted out the issue:
http://discussions.apple.com/thread.jspa?messageID=2186542&#2186542
Kerberos is running now but still canna login for mac clients.
hostname and sso_util info -g both resolve properly.
but when i run:" slapconfig -kerberize diradmin REALM_NAME "
all looks good until the command (with the proper substituions)
"sso_util configure -r REALM_NAME -f /LDAPv3/127.0.0.1 -a diradmin -p diradmin_password -v 1 all"
automatically runs and I get a list of:
SendInteractiveCommand: failed to get pattern.
SendInteractiveCommand: failed to get pattern.
SendInteractiveCommand: failed to get pattern.
and "sso_util command fialed with status 2"
the sso_util command by itself spits out
Contacting the directory server
Creating the service list
Creating the service principals
kadmin: Incorrect password while initalizing kadmin interface
SendInteractiveCommand: failed to get pattern.
kadmin: Incorrect password while initalizing kadmin interface
SendInteractiveCommand: failed to get pattern.
kadmin: Incorrect password while initalizing kadmin interface
SendInteractiveCommand: failed to get pattern.
etc...
even though the login/pass are good
any thoughts on what i should check or where i should go next?
Thanks
Mitch
iMac G5 Mac OS X (10.4.6)
iMac G5 Mac OS X (10.4.6)

Why Can't VZ do the Right Thing For Once and Permit Network Extender Owners to Close their Networks?

Given the fact that the Network Extender can be set for managed access or open access, clearly it can technologically be configured so that a closed network could be set up so that ONLY those users that are included in the "priority list" could access the Network Extender.
If I had to guess, Verizon, prefers to benefit from your internet connection and your investment in a network extender by bolstering their network in poor reception areas for all of their customers in the vicinity on us Network Extender owners' backs rather than to do the right thing and permit a customer who has paid for the device as well as their internet access to close the network.
I find this sleazy and hope VZW will rethink its approach to this. We who subscribe to VZW for our cellular service pay the highest rates, on average, in the country for cell service. We have also paid hundreds of dollars for the Network Extender, and pay for the internet that is used to facilitate the phone calls made through the network extender.
Once it a while it would be nice if VZW did the right thing for its customers and not blatantly, at least, put their corporate greed about the needs of their customers.

I called Verizon tech support, and was informed that there is an option to close the Network Extender. This would allow only numbers on the white list to connect to the extender. Is the information I received incorrect? I spoke to them just the other day. Have you tried to configure the extender recently?
My post asking for clarification is here: https://community.verizonwireless.com/message/1002928#1002928
Thanks for any information you can provide.

Permissions for package owner for kill session?

What permissions does a package owner need to execute immediate 'alter system kill session' within a package?

Are you sure? It works for me on 10.2.0.1 (32 bit Windows)
SYS @ jcave102 Local> drop user bob cascade;
User dropped.
Elapsed: 00:00:11.25
SYS @ jcave102 Local> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
Elapsed: 00:00:00.10
SYS @ jcave102 Local> create user bob identified by bob default tablespace users;
User created.
Elapsed: 00:00:00.07
SYS @ jcave102 Local> grant create session, create procedure, alter system to bob;
Grant succeeded.
Elapsed: 00:00:00.01
SYS @ jcave102 Local> conn bob/bob
Connected.
1 create or replace procedure kill_session( p_sid in number, p_serial# in number )
2 as
3 begin
4 execute immediate 'alter system kill session ''' || p_sid || ',' || p_serial# || '''';
5* end;
BOB @ jcave102 > /
Procedure created.
Elapsed: 00:00:00.57Now, find a session to kill (using a user other than BOB who doesn't have permission to view the V$SESSION table) and call the procedure
BOB @ jcave102 Local> exec kill_session( 144, 115 );
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00Justin

AFP inherit perms directories inherit owner!

Similar Messages

Maybe you are looking for