Home › Forums › OS X Server and Client Discussion › Questions and Answers › Tiger 10.4.11 Server – Leopard Client Folder Permission Problems
- This topic has 7 replies, 4 voices, and was last updated 15 years, 8 months ago by
delawarecreative.
-
AuthorPosts
-
January 21, 2008 at 6:55 pm #371184
tmolesky
Participant[b]Environment: [/b]
Server:Tiger 10.4.11 Server with attached RAID
Clients: 10 Mac Pros and G5s, running Tiger 10.4.11
3 Mac Pros Running Leopard 10.5.1
All Users have their own user name/password to authenticate to share
Server is set as a [b]Standalone Server[/b]
[b]
Problem:[/b]When Macs running Leopard make new folders on AFP Shares, permissions are [b]Read and Write[/b] to that user only, [b]Read Only [/b]to Everyone else. This seems to have just started.
So if Joe Smith on Mac with Leopard logs on to the Xserve’s AFP Share and Creates or Copies over a folder, [i]only he[/i] can read and write to it. Only a Leopard User can change permissions via “Get Info”, or the Xserve admin.
This is causing absolute chaos. Please help
Thank you in advance.
January 22, 2008 at 4:06 am #371192martin.howell
ParticipantI’m saving the same problem at my company. Our environment is identical save subbing the Leopard clients with a hand full of XP Pros. Our probs actually started back in Dec (maybe Nov?) ’07. More recently we began to loose files and hardware was suspected. We’ve since purchased a brand new Xserve and installed Leopard Server. That was actually started by a co-worker at the beginning of last week and I picked up the project this week. There were failed service issues between us both and I experienced file access issue (complete with nasty error messages) where I shouldn’t have. Every call to AppleCare resulted in a suggestion of a reboot which of course fixes things for 20 minutes up to 24 hrs. Not acceptable even for a test server, which this is NOT.
We decided today to downgrade to Tiger Server. That went mostly fine and we even have it joined to Microsoft Active Directory. Everything seems fine except for file ownership and permissions not propagating or being inherited properly. We would like our setup to have new folders/files inherit the exact same permissions/access as the parent folder.
I’ll be giving AppleCare another call in the morning. I’ve already spent all day getting this far. Surprisingly I’m not tired but I’ve leaving before frustration gets the best of me.
Sorry for all the unessary talk, just clearing my head I guess…
I’ll post back after AppleCare convo. Hopefully they’ll have something helpful.
January 22, 2008 at 4:31 am #371193tmolesky
ParticipantWell, I have some good news after 30 minutes with a great OSX Server Support person at Apple. He basically replicated the problem on his end, acknowledging that A. I am not nuts, or a bad network administrator B. That it can be resolved.
I did not have ACL’s enabled for the two groups that I had set up to access Share A and Share B, which are two separate folders on the same RAID.
Group A has Access to [i]both[/i] Share A and Share B
Group B [i]only[/i] has access to Share BI had POSIX Permission set up the following way:
[b]Share A[/b]
Owner: Admin – Read & Write
Group: Group A – Read & Write
Everyone: None[b]Share B[/b]
Owner: Admin – Read & Write
Group: Group B – Read & Write
Everyone: Read & WriteHe told me to put Group A on The Access Control List:
Group A / Allow / Full control
Group B / Allow / Full control (add Group B to Group A list)and set both shares to:
Owner: Admin – Read & Write
Group: Group staff Read Only
Everyone: Read Only
These are the standard default settings – it did not work. same problems with Leopard Clients, Read-only access now from Tiger ClientsI set the POSIX permissions back to what I had them above and it worked! i am not sure why, as ACL should override any POSIX behavior.
Leopard clients can now create folders and documents that the Tiger users can rename, save, edit and/or delete.I hope this helps anyone who is ripping their hair out in clumps like I was before getting some help.
January 22, 2008 at 5:01 am #371195martin.howell
ParticipantI’ll give that or some variant a shot but in my case I was already using ACL’s AND just as you the ACL’s did not take precedence (as the tip in the GUI states). I would much rather use ACL’s throughout.
One thing is confusing me however with your post:
>He told me to put Group A on The Access Control List:
>Group A / Allow / Full control
>Group B / Allow / Full control (add Group B to Group A list)
Did you add GroupB as a member of GroupA? This seems to defeat the purpose of having two groups, one that you may want to have restrictive access.Also, What is “Group: Group staff Read Only”. I’ve not seen this.
Thx
January 22, 2008 at 5:16 pm #371206martin.howell
ParticipantThx – I’ll search for the whitepaper.
—————
Found these two, I’ll post here to save others the search:
https://www.afp548.com/filemgmt/index.php?id=40
https://www.afp548.com/article.php?story=20060122204418624&query=acl-Martin
July 29, 2009 at 6:51 pm #376742delawarecreative
Participantwe are having similiar issues all starting when we upgraded our windows AD server to server 2008 enterprise 64 bit.
Previously we had os 10.4 x server with AD on a windows 2003 sbs premium server. the issues were not nearly as frequent.
I upgraded the mac server to os 10.5.x server reading that this fixed some permissioning issues, but they still existed.
in fact, they are very frequent, were I am manually resetting the permission on the parent folder almost every hour.I have worked with apple engineers to no avail.
we installed the server os on a new hard drive (clean install) created a new share point off the boot volume, bound it with AD and still had the same permission issues.we removed acls, added acls, changed the posix permissioning and nothing seems to fix this.
it is very frustrating. If you have been able to resolve these issues, please contact me.
Anyone successfully able to help resolve this issue, will be paid for consulting.
Thanks in advance,
Jamie Walker -
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed