Subject: Re: chown invalid argument (was: Re: AW: Still Only Cleartext)
From: Axel Bringenberg (A.Bringenberg@srz-berlin.de)
Date: Mon Mar 05 2001 - 15:45:02 EST
And here is the next:
I found that in ./etc/afpd/volume.c the line
#define VOLOPT_MAX 9
was changed to
#define VOLOPT_MAX 11
Changing back to 9 fixes the "chown 16777216/-1" problem, but the "chown
-1/0" still remains. Can someone check this?
Still hunting,
- Axel
Axel Bringenberg schrieb:
>
> Hi,
>
> inspired by the bug report
> http://sourceforge.net/tracker/index.php?func=detail&aid=405434&group_id=8642&atid=108642
> I have diff'ed the source of ./libatalk from 1.5pre4 against 1.5pre3:
> Someone has changed line 617 of ./libatalk/adouble/ad_open.c from
> admode = ad_mode( ad_p, mode );
> to
> admode = ad_mode( ad_p, O_RDWR );
> This is the only difference in the c source of libatalk.
>
> I have changed the line back to the old version and now my problems are
> partly gone: I have still log entries like "chown 16777216/-1" and
> "chown -1/0" with . and .AppleDouble/.Parent while drag'n'drop files to
> the server folder, but no more "access denied" error messages on the
> clients side and the file permissions are looking imho fine to me.
>
> Can someone explain the change in libatalk?
>
> - Axel
>
> Axel Bringenberg schrieb:
> >
> > I'm just wondering why the _user_ process tries to set a gid of 0 or an
> > uid of 16777216 (0x1000000) ?! Hmm...
> >
> > - Axel
> >
> > Keith Lamont schrieb:
> > >
> > > Same here, except I tried the .rpm before building from scratch, and
> > > only tested against Mac OS 9. I'm not a total stranger to netatalk;
> > > had it running with RH 5.2 on another box.
> > >
> > > Keith
> > >
> > > >Hi Marc,
> > > >
> > > >"Marc J. Miller" schrieb:
> > > >>
> > > >> Looks familiar to me too.
> > > >>
> > > >> If you're using a netatalk 1.5 prerelease and you have either ADMIN_GRP or
> > > >> DROPKLUDGE turned on, I think that's my bailiwick and I need to know what
> > > >> platform and flavor you two using to fix it (e.g. Red Hat Linux 7, FreeBSD,
> > > >> Debian Linux 2.2, etc.). That's an awfully large uid, though... 16 million
> > > >> user names is a lot. Is it possible that the number is too big and we've
> > > >> run into a limitation of chown?
> > > >
> > > >No, I don't think so. I've been fighting against the same problem too
> > > >and in my case I'm today the only user of a fresh installed rh7.0 box:
> > > >
> > > >------------<snip>-----------------------------------
> > > >Feb 28 17:27:33 gromit afpd[18327]: cleartext login: bringi
> > > >Feb 28 17:27:33 gromit PAM_pwdb[18327]: (netatalk) session opened for
> > > >user bringi by (uid=0)
> > > >Feb 28 17:27:33 gromit afpd[18327]: login bringi (uid 500, gid 500)
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown 16777216/-1
> > > >.AppleDouble/.Parent: Invalid argument
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown 16777216/-1
> > > >.AppleDouble: Invalid argument
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown 16777216/-1 .:
> > > >Invalid argument
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown -1/0
> > > >.AppleDouble/.Parent: Operation not permitted
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown 16777216/-1
> > > >.AppleDouble/.Parent: Invalid argument
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown 16777216/-1
> > > >.AppleDouble: Invalid argument
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown 16777216/-1 .:
> > > >Invalid argument
> > > >Feb 28 17:27:36 gromit afpd[18327]: setdirowner: chown -1/0
> > > >.AppleDouble/.Parent: Operation not permitted
> > > >Feb 28 17:28:01 gromit afpd[18327]: setdirowner: chown -1/0
> > > >.AppleDouble/.Parent: Operation not permitted
> > > >Feb 28 17:28:27 gromit afpd[18327]: logout bringi
> > > >------------<snip>-----------------------------------
> > > >
> > > >This happens everytime while moving, copying or creating files -
> > > >directories are doing fine. Is it possible that some pieces of the new
> > > >(and broken) FORCE_UIDGID code is still active? Or is it maybee a
> > > >Redhat-only problem?
> > > >
> > > >I've looked arround and found some similar messages in this list, all
> > > >reporting problems with
> > > > setdirowner: chown -1/0 .: Operation not permitted
> > > >or setdirowner: chown -1/0 .AppleDouble/.Parent: Operation not permitted
> > > >or setdirowner: chown 16777216/-1 .: Invalid argument
> > > >or setdirowner: chown 16777216/-1 .AppleDouble/.Parent: Invalid argument
> > > >
> > > >Most of them using rh7.0 (or mdk) and netatalk since 1.5pre3.
> > > >
> > > >In my case I've ...
> > > >- build a freshly RH7.0 box with all possible updates (incl.
> > > >kernel-2.2.17-14)
> > > >- build netatalk-1.5pre4 from source w/o ADMIN_GRP, DROPKLUDGE and
> > > >FORCE_UIDGID
> > > >- I'm the first and only additional user (uid 500/gid 500)
> > > >- the volume is totaly owned by me (maximum chowned and chmoded :-)
> > > >- tested with MacOS 7.5, 8.6 and 9.0
> > > >
> > > >Axel.
> >
> > --
> > Satz-Rechen-Zentrum Berlin - Systemgruppe
>
> --
> Satz-Rechen-Zentrum Berlin - Systemgruppe
-- Satz-Rechen-Zentrum Berlin - Systemgruppe
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:33 EDT