Subject: Re: chown invalid argument (was: Re: AW: Still Only Cleartext)
From: Axel Bringenberg (A.Bringenberg@srz-berlin.de)
Date: Mon Mar 05 2001 - 12:39:44 EST
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
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:33 EDT