Subject: Permissions icons not showing up properly

From: "Kevin M. Myer" <[email-masked]>
Date: Thu, 28 Dec 2000 11:20:53 -0500 (EST)

Hello,

I am using netatalk 1.5pre3 on Red Hat Linux 6.2 on x86
hardware.  I have a Departments folder setup with 7 department folders
underneath the main folder.  Each sub-folder is setup so that only members
of that department can access it, which is done via groups.  The top-level
folder is read-only so that no one can delete the entire department folder
accidently.  Now normally when a user logs in, they open the Department
folder.  Then what they normally see is a window with a pencil with a line
through it (the read-only icon in the upper left hand corner of the
window).  And all the department folder icons have the belt buckle around
them, except for the department they are a member of.  That was normal, as
of yesterday.

Yesterday morning, I began moving files from three other servers to this 
new server.  I attempted to change ownership of the folders from myself to
the proper owner - that didn't work obviously because I was just a normal
user.  So I added the -admingroup option to the afpd.conf file and
restarted netatalk.  After doing this, I found that I now had full access
to move folders around but I still was getting EPERM denied errors when
trying to change owners on folders.  I tried copying permissions to all
enclosed folders which failed as well.  

Well, after I did this, I removed the -admingroup option from afpd.conf
and restarted netatalk again.  Unfortunately, the windows and folders no
longer indicate read-only access or no access.  Instead, the windows are
normal and the folders are normal (i.e. no slashed pencil or belt-buckle).  
And instead of getting an access denied error when trying to click on a
folder I don't have permission to, I now get a "The folder XXX cannot be
opened because it cannot be found".  strace shows the following:

chdir("test/.")                   = -1 EACCES (Permission denied)

I'm sure that I've just managed to get a bit set somewhere wrong, perhaps
with my attempt to copy permissions to enclosed folders.  I'd really like
to get back to having the buckled icons and the read-only windows, as well
as error messages which accurately reflect whats really going on.

I'd appreciate any feedback relating to the permissions display, as well
as any information regarding the -admingroup option (i.e. why it isn't
giving me administrator rights on the server).

Thanks,

Kevin

-- 
Kevin M. Myer
Systems Administrator
Lancaster-Lebanon Intermediate Unit 13
(717)-560-6140

---

From: Marc Miller <[email-masked]>
Date: Fri, 29 Dec 2000 00:14:47 -0800 (PST)

I saw that too & I'm not quite sure what to make of it.  Unfortunately,
the office is closed until after New Years & I can't get in there to test
fixes for another week or so.

Has anyone else seen this problem?

> giving me administrator rights on the server).

============================================================
	/\/\arc ._|. /\/\iller ([email-masked])
	Computer Room Consultant
	Information Technology/Lab Management
============================================================
I can be contacted through the Communication Center link from
http://www.mother.com/~mjmiller/

---

From: [email-masked]
Date: Fri, 29 Dec 2000 17:22:01 +0100

hi there,

here are always problems copying files from different os-versions to a
netatalk-server. mac says "error -50"

suggestions would be great...

thanks again,
seb

---

From: Frank Joerdens <[email-masked]>
Date: Fri, 29 Dec 2000 17:40:11 +0100

> netatalk-server. mac says "error -50"

I seem to recall that someone found this error to be related to filename restrictions
imposed by a volume-specific configuration option such as -mswindows (if you want netatalk
to work with samba), and then someone trying to copy a file with a name that was
disallowed (e.g. containing a colon). Try searching the list archive for more info.

Regards,
Frank

---

From: "Kevin M. Myer" <[email-masked]>
Date: Fri, 29 Dec 2000 12:18:44 -0500 (EST)

> Has anyone else seen this problem?

Whatever the problem is, I believe I've narrowed it down to a change that
occured between 1.4.99-20001108 and 1.5-pre3.  The reason I inadvertantly
attributed the permission problem to the -admingroup option was that I
hadn't restarted my netatalk daemons after upgrading to 1.5-pre3.  When I
restarted the daemons I did two things - launch a newer afpd and also run
with the -admingroup option.  I dropped back to 1.4.99-20001108 and
folders now reflect permissions as they should.  Having an up-to-date and
accurate ChangeLog would be REALLY helpful in tracking what changed
between releases and in finding this apparent bug.  Oh, well - time to
diff away I guess.

Kevin

---

From: "Kevin M. Myer" <[email-masked]>
Date: Fri, 29 Dec 2000 14:11:31 -0500 (EST)

Ok, it looks like the problem crops up in etc/afpd/directory.c and stems
from a call to the accessmode function in the DIRPBIT_ACCESS case.  My
guess is that accessmode returns something that either a) clobbers
something in the ma structure that was modified by utommode or b) doesn't
return a complete set of information in the ma structure.  As the
accessmode function appears to have been lifted from etc/afpd/afs.c, I
suspect that this problem always existed if you used AFS - but maybe very
few people are using it and netatalk together.  I further suspect that
someone saw the function, thought it looked good and decided to use it
instead of/in addition to utommode.

I've never been a UNIX programmer (wish I knew more) but thats my take on
where the problem lies.  I commented out the offending function call in
directory.c and my icons now reflect permissions properly.  As I said, I
suspect accessmode needs a wee bit more work so that it properly grabs a
directory's permissions.

The real simple patch is:

--- netatalk-release/etc/afpd/directory.c.old   Fri Dec 29 14:02:19 2000
+++ netatalk-release/etc/afpd/directory.c       Fri Dec 29 14:02:35 2000
@@ -943,9 +943,9 @@
 
        case DIRPBIT_ACCESS :
            utommode( st, &ma );
-#ifdef HAVE_ACCESS
+/* #ifdef HAVE_ACCESS
            accessmode( upath, &ma, dir );
-#endif HAVE_ACCESS
+#endif HAVE_ACCESS */
 #ifdef AFS     /* If only AFS defined, access() works only for AFS
filesystems */ 
            afsmode( upath, &ma, dir );
 #endif AFS

Kevin

---

From: Thomas Schierle <[email-masked]>
Date: Sat, 30 Dec 2000 01:03:36 +0100

> Has anyone else seen this problem?

Finally managed to install pre-3 last night, and on a freshly created
sharepoint (775) the user who created "Network Trash Folder" (first who
logged in) can *see* the trash folder.

When trying to access U&G rights for that folder, "the item is not
available". The problem persists for that user even on subsequent logins.

-- 
Thomas Schierle, Munich, Germany

PGP key [DSS/DH] 0xA23CDA1D available at various public key servers