Public folder permissions problem

TheQL

Registered
Hello,

when switching from OS9 to OSX our users seemed to be a little confused about the public folder, behaving differently as they were used to from just sharing any folder you liked on OS9.

So what I did was deleting the Dropbox and giving full read and write access to the public folder to anyone, which helped.

But there is a problem which I am not sure if it is connected to that. Quite often it happens, that users copy files to another users public folder and there it cannot be opened or if it can, it can't be deleted anymore until you manually change the ownership and the file permissions. Why does that happen?

Files put into the public folder of another user should be created with ownership to the computer owner and not someone else, also all files in the public folder should be readable by all and when copied to the local computer become owned by the local computer user.

How can I achieve this? Tnx!
 
The person putting the file in the drop box, or in the public folder (whichever) remains the owner of the file. If they set the permissions on the file funny, that's the way they stay, barring admin intervention.

You should be able to delete the file though - all you're writing to when you delete a file is actually that file's parent directory. Slightly complicated why that is, but...

You also can't modify the file if you don't have write permission, but you can overwrite it (delete, then make one with the exact same name).
 
First of all thanks, but are you saying, that the newly created file gets the same UID as the owner on the "sending" machine? This UID could be not assigned or it could even BE assigned to what user ever on my machine. This is weird.

So, what is happening on our machines is normal behaviour? Although I'm not sure if you can delete the file without manually changing the permissions with an admin account. Creating a new file depends on the permissions of the parent folder, but an already existing file has its own permissions and deleting equals writing, right? So if I was able to delete the file I should as well be able to modify it, which I'm not.

In general I think this is a weird implementation. It cannot be that people put files on my machine which I can't read or edit. The permissions should be changed on fly during the copy process.

Most Mac OS X users haven't even heard of file permissions before, now tell them how to deal with that.
 
Nobody got any more ideas?

I will check more if this also occurs when not AppleTalk but SMB is used. And I am not sure if this problem, that the owner of a machine, even if logged in as admin, should find files in his public folder which he cannot read or write. Isn't it normal, that files are not world-writable? How can you change the default umask of files created on the machine? I could then set this to 777 and work around the problem.
 
I have the same exact problem. I have an idea on how to fix it, but I have not had time to work on it:
Use an Applescript as a Folder Action to change the permissions of files added to the folder. I don't think you can do it in AppleScript alone; it would have to call a shell script. The script would have to break the rule of not storing your password, but I think I can risk it in my environment.
 
Back
Top