Subject: Re: permissions prob
From: Karen A Swanberg (swanberg@tc.umn.edu)
Date: Tue May 08 2001 - 15:38:06 EDT
> > on 05/08/01, Peter Risdon wisely declared:
> >
> > > When my client tries to copy a folder to the network share, he gets an
> > > error stating he has insufficient permissions, and the following appears
> > > in /var/log/messages:
> > >
> > > -- May 8 10:47:24 gateway afpd[56796]: setdirmode: chmod .AppleDouble:
> > > Operation n
> > > ot permitted
> > > May 8 10:49:26 gateway afpd[56796]: setdirmode: chmod .AppleDouble:
> > > Operation n
> > > ot permitted
> > >
> > > I'm puzzled because the setup is simple and one I've used elsewhere,
> > > including in my own office. The server is FreeBSD 4.2 and
> > > AppleVolumes.default just states:
> > >
> > > ~
> > > /shared/directory/path
> > >
> > > The share is also used by samba. permissions of the share are 777.
> > >
> > > Any ideas?
> > >
>
> On Tue, 8 May 2001, Karen A Swanberg wrote:
>
> >
> > Which version of Netatalk are you running? This was a known problem in the
> > 1.5pre5 version, fixed in 1.5pre6. I believe it was also a common problem
> > in the 1.4b2, but don't remember for sure.
> >
> > If you search the mail archives, there are extensive notes on this. I
> > can't get to the archive FTP site at the moment to pull up the relevant
> > discussions, but they're also available on the web at:
> >
> > http://endofdays.rs.itd.umich.edu/~tombeau/netatalk/mail.html
> >
> > and via ftp at:
> >
> > ftp://terminator.rs.itd.umich.edu/unix/netatalk
> >
> > -Karen
on 05/08/01, Daniel E. Lautenschleger wisely declared:
> I get a similiar response with Pre6.
>
> -Dan
Hm. When I was having similar problems with 1.5pre6, , it was because I
hadn't completely removed the old binaries from my system, and they were
still getting called at unexpected times. If the end user is still getting
the errors when they try to access the volume from the client, after a
clean install and a reboot(?), I don't have any more suggestions. The
.AppleDouble errors in the error log or console on the server, though,
without corrosponding problems on the client is due to a slight problem
with the error logging, and is not a real problem. It's been fixed
in the CVS version, but I haven't yet been able to get that one to
compile due to CVS issues on my end.
Copied from an e-mail from Andrew Morgan:
Subject: Re: .AppleDouble tests on OpenBSD (long...)
Date: Wed, 25 Apr 2001 10:19:41 -0500 (CDT)
> > Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown 16777216/-1
> > .: Operation not permitted
> > Apr 23 16:30:20 epidote afpd[25250]: setdirowner: chown -1/0
> > .AppleDouble/.Parent: Operation not permitted
> >From my investigations tonight (whew!), these are not really errors.
> Just to clarify what is happening above:
> These are all being triggered by calls to FPSetDirParms from the
> mac. It
> passes a big structure full of permission bits, user and group ids,
> etc. In the current code, when the chown fails, we call syslog at
> LOG_ERR level. In the asun2.1.4 code, it called syslog at LOG_DEBUG
> level. In both cases, no error was passed to the mac client because
> really, afpd should deal with this operation properly or just ignore
> it. At the LOG_DEBUG level, most users never saw the "error".
>
> Somewhere around revision 1.6 of etc/afpd/unix.c, someone changed the
> LOG_ERR to LOG_DEBUG, apparently in the throes of adding dropkludge
> support. If there was a valid reason for the change, please speak up.
> Otherwise, we should change those back to LOG_DEBUG so we don't scare
our users.
> Andy
So to clarify for the newbies, this breaks down to "This isn't a problem?"
We just need to tell our sysloggers to ignore it? Are the errors
catagorized as something like afpd.error or something similar that we can
configure our syslogs to ignore? I don't want to miss other errors, or
have my console window so full of this information that I miss others. If
and when the change is made in the CVS, will someone post here, so I can
test that new version?
-Karen
--end copy--
Now, of course your error is 'chmod' instead of 'chown,' of course, so
this might not apply.
Not a bad idea to reply to the list, so they know if a solution doesn't
work. But I'm just a newbie here, so take my words with a largish grain
of salt...
-Karen
* *
Karen Swanberg |
Network Admin. | GNUmusk, an
Dept. of Geology/Geophysics | opensource cologne
206 Pillsbury Hall |
310 Pillsbury Ave. SE | Old geeks never die
University of Mn | They just revert
Minneapolis, MN 55455 | to cleartext
(612) 624-6541 |
* *
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:39 EDT