Genius want a cookie...? (permissions problem)
Thought that might get your attention. :cool:
Okay, here's the situation, and if someone here can't answer it, I give up... (and yes, this was a question i asked before, but it didn't garner much response at the time. since then i have gathered more info, but no resolution, so i am posting again):
The Situation:
We have a mixed Mac/PC network at work. My studio is 10 Macs running OS X.2.2, logging into common shared volumes via AFP on our Windows2000 server (running IIS). Now every time someone logs in, and creates a new directory on the server volume, it is locked out to all users but the one who created it (owner is listed as "kmem"). The owner can change this to read/write for all others, but often times, no one will remember to do this since it's just habit to create a folder and forget about it. yet when someone else logs in from another client, they can't manipulate the directory. and if you forget who made the directory to begin with, you either have to try loggin in as different users until you get the right one, or boot into OS 9, which shows you the actual user (instead of "kmem") and change the privileges. And, while Jaguar allows you to "ignore permissions," it apprently doesn't work with mounted remote volumes... like, say, a Windows2000 server volume.
A friend of mine offered this advice, which sounds good, but didn't help:
[quote]Yep. I was able to duplicate it here, but I think I've got a workaround.
Now I did this on server that is on an AD domain. If your server isn't doing domain security it might not work.
1.) Make a global security group on the domain and insert all of the users.
2.) At the root of your share give the group full control NTFS permissions (the Secruity tab).
This should handle whatever goofy inheritence thing is happening here. The members of the group should also have full control, as the combination of default inheritence behavior and the existence of the group should take care of it. Weird......<hr></blockquote>
Unfortunately, it didn't work (all new directories STILL have an owner of "kmem"). According to OSXFaq.com (edited for space and readability), this isn't entirely surprising:
[quote]
The kernel runs with four different levels of security. Any superuser process can raise the security level, but only init can lower it. Security levels are defined as follows:
(-1)Permanently insecure mode - always run system in level 0 mode.
(0) Insecure mode - immutable and append-only flags may be turned off.
All devices may be read or written subject to their permissions.
(1) Secure mode - immutable and append-only flags may not be changed; disks for mounted filesystems, /dev/mem, and /dev/kmem are read-only. The settimeofday(2) system call can only advance the time.
(2) Highly secure mode - same as secure mode, plus disks are always read-only whether mounted or not...
Normally, the system runs in level 0 mode while single user and in level 1 mode while multiuser...If it is desired to run the system in level 0 mode while multiuser, the administrator must build a kernel with "option INSECURE" in the config file.<hr></blockquote>
Great, so unless i either a.) rebuild the kernel or b.) give everyone root access to their computer, this will always happen??? Ugh. <img src="graemlins/oyvey.gif" border="0" alt="[No]" />
Methinks there's an answer somewhere in NetInfo Manager, but darn if i can figure out where.
Please tell me someone has an idea...
P.S. Just so you know, someone started asking this same question at a recent seminar at Apple Canada's campus, when the Apple Rep cut him off in mid sentence with "Yes, we are aware of the problem, and we hope to have it resolved as soonas possible..." Fat lot of good that does ME...
[ 12-12-2002: Message edited by: rok ]
[ 12-13-2002: Message edited by: rok ]</p>
Okay, here's the situation, and if someone here can't answer it, I give up... (and yes, this was a question i asked before, but it didn't garner much response at the time. since then i have gathered more info, but no resolution, so i am posting again):
The Situation:
We have a mixed Mac/PC network at work. My studio is 10 Macs running OS X.2.2, logging into common shared volumes via AFP on our Windows2000 server (running IIS). Now every time someone logs in, and creates a new directory on the server volume, it is locked out to all users but the one who created it (owner is listed as "kmem"). The owner can change this to read/write for all others, but often times, no one will remember to do this since it's just habit to create a folder and forget about it. yet when someone else logs in from another client, they can't manipulate the directory. and if you forget who made the directory to begin with, you either have to try loggin in as different users until you get the right one, or boot into OS 9, which shows you the actual user (instead of "kmem") and change the privileges. And, while Jaguar allows you to "ignore permissions," it apprently doesn't work with mounted remote volumes... like, say, a Windows2000 server volume.
A friend of mine offered this advice, which sounds good, but didn't help:
[quote]Yep. I was able to duplicate it here, but I think I've got a workaround.
Now I did this on server that is on an AD domain. If your server isn't doing domain security it might not work.
1.) Make a global security group on the domain and insert all of the users.
2.) At the root of your share give the group full control NTFS permissions (the Secruity tab).
This should handle whatever goofy inheritence thing is happening here. The members of the group should also have full control, as the combination of default inheritence behavior and the existence of the group should take care of it. Weird......<hr></blockquote>
Unfortunately, it didn't work (all new directories STILL have an owner of "kmem"). According to OSXFaq.com (edited for space and readability), this isn't entirely surprising:
[quote]
The kernel runs with four different levels of security. Any superuser process can raise the security level, but only init can lower it. Security levels are defined as follows:
(-1)Permanently insecure mode - always run system in level 0 mode.
(0) Insecure mode - immutable and append-only flags may be turned off.
All devices may be read or written subject to their permissions.
(1) Secure mode - immutable and append-only flags may not be changed; disks for mounted filesystems, /dev/mem, and /dev/kmem are read-only. The settimeofday(2) system call can only advance the time.
(2) Highly secure mode - same as secure mode, plus disks are always read-only whether mounted or not...
Normally, the system runs in level 0 mode while single user and in level 1 mode while multiuser...If it is desired to run the system in level 0 mode while multiuser, the administrator must build a kernel with "option INSECURE" in the config file.<hr></blockquote>
Great, so unless i either a.) rebuild the kernel or b.) give everyone root access to their computer, this will always happen??? Ugh. <img src="graemlins/oyvey.gif" border="0" alt="[No]" />
Methinks there's an answer somewhere in NetInfo Manager, but darn if i can figure out where.
Please tell me someone has an idea...
P.S. Just so you know, someone started asking this same question at a recent seminar at Apple Canada's campus, when the Apple Rep cut him off in mid sentence with "Yes, we are aware of the problem, and we hope to have it resolved as soonas possible..." Fat lot of good that does ME...
[ 12-12-2002: Message edited by: rok ]
[ 12-13-2002: Message edited by: rok ]</p>
Comments
I have seen similar problems with the Windows NFS server; we eventually gave up and switched to Linux. I would suggest you use an OS X file server and save yourself a lot of pain.
we just upgraded TO it (trust me, not my call), and spent a TON of money in doing so, so the server config ain't changing.
hopefully someone will find an answer. i sent it in to macfixit, but gettign answers from them (or getting posted, or searching for an answer on the forums) is like finding a needle in a haystack. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
FINALLY!
guess apple gets the cookie.