Subject: [netatalk-admins] SOLVED(?): Shared Trash Problem
From: Neil McAllister (nmcallister@primo.com)
Date: Wed Aug 26 1998 - 00:18:15 EDT
OK, earlier today I posted a question about netatalk giving me the "Do you
want to delete this immediately?" message when more than one user tried to
put things into the trash on a shared volume. I couldn't believe this was
"just the way it was" with netatalk -- such improper behavior! -- but a
quick read of the netatalk-admins archives showed that this problem had
indeed popped up in the past, and that nobody had yet figured it out.
Bob Smith (bsmith@h-e.com) posted the one "fix" I found. I didn't read his
code and what he changed, but his fix involved patching afpd, and then
going in and manually creating all the "Trash Can #?" folders inside the
Network Trash Can folder, one for each individual user on the system. I
didn't even bother to look into this any further, cuz with some 40+ users
to support on this machine (and new users coming and going with some
regularity) I knew it would be completely unmanageable, and so esoteric
that nobody but myself would ever be able to figure it out after I leave.
(Hey -- I wanna quit this job sometime, you know!)
Interestingly enough, Bob later said that he believed the eventual fix
would be an easy one, but that he didn't think it was a permissions
problem. Well -- I'm here to tell you it IS a permissions problem. I'll
explain, but first I'm going to post my entire fix (see if you like the
look of mine better than Bob's):
CAVEAT: This "fix" will likely only work in a situation where all of your
netatalk users are in at least one common group, e.g. "macusers".
--------------------------------[cut here]-----------------------------------
NOTE: For purposes of this example, macadmin is any hypothetical user,
while macusers is a hypothetical group which MUST contain all the UIDs
which will be accessing your netatalk share.
1. Go to [netatalk source dir]/etc/afpd/unix.c and change line 26 to read:
#define DIRBITS S_ISGID | S_IWGRP
Recompile afpd, and then start up netatalk and afpd as usual.
2. Go to the netatalk root shared directory where you're having the
problem, and do the following:
rm -rf Network\ Trash\ Folder
mkdir Network\ Trash\ Folder
chown macadmin:macusers Network\ Trash\ Folder
chmod 2777 Network\ Trash\ Folder
------------------------------[cut here]--------------------------------------
Do that -- AND YOU'RE DONE! Your trash should be functioning properly. It
should be making the "Trash Can #xx" folders properly for each user, and
deleting them as the users log out of the volume. (Note that for Bob's
patch, you needed to create a Trash Can folder by hand for each individual
user, and then leave it lying around all the time. Ugly.)
WHY MY HACK WORKS:
Ok, I said that the Network Trash Folder problem was indeed a permissions
problem. The reason it didn't seem like it, to a lot of people, is because
it's the kind of permissions problem that no Unix admin would likely
imagine.
What seems to be the case, is that for the network trash to operate
properly, the Network Trash Can and the Trash Can Usage maps need to be
world read-writeable. But the "Trash Can #xx" files are a special case.
Get this -- for whatever reason, in order to interpret those directories
properly, the Appleshare client just needs to see that they are WRITABLE.
Make sure you're clear on that -- it doesn't matter if they're readable.
It doesn't matter if they're executable. Just writable. So for Unix
purposes, the user can't actually DO anything with someone else's Trash
Can. You can't stat it, you can't copy anything to it. (Am I wrong?)
Still, by making them writable, all the "Do you want to throw it away
immediately?" problems seem to disappear.
I have no explanation for this -- I don't understand the workings of the
Appletalk protocol, or of netatalk for that matter, one bit. But this is
just the behavior I observed this afternoon/evening.
SO WHAT DID I CHANGE?
Netatalk does a procedure where it does a chmod g+s on each new directory
it creates. To my mind, at least in the Macintosh file-sharing model, it
doesn't make much sense to create a directory SGID unless it is also
writable. So I just changed the code in "unix.c" so that whenever afpd
creates a directory, it does a chmod g+ws instead of just g+s.
The downside is that every new directory that's created on a netatalk share
with this hack will be Group Writeable. But then -- on my system that
seems to always be the case anyway?? If anyone can find fault with this, I
want to hear about it, before I make a big mistake!!!
The other part of it was creating a "clean slate" Network Trash Folder. If
you create a folder like I show, make it SGID and world
read-write-executable, then the Trash Can Usage Map and the .AppleDouble
folders within will get created with the correct permissions automatically.
If the Trash Can Usage Map isn't world read-writeable, this won't work.
Does it sound good?? I just put in a 12-hour day at the office trying to
figure this bullshit out, so if anyone tells me I've contributed something
useful I'll be really happy.
Cheers!
-- Neil McAllister, Systems Administrator Primo Angeli Inc., San Francisco, CA, USA http://www.primo.com mailto:nmcallister@primo.com
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:10 EST