Subject: Re: Serious Problems
From: Dejan Muhamedagic (dejanm@aon.at)
Date: Wed Jun 07 2000 - 06:32:00 EDT
Hello,
On Wed, Jun 07, 2000 at 01:12:47PM +1000, Luke McNeilage wrote:
>
> >From: Dejan Muhamedagic <dejanm@aon.at>
> >To: <netatalk-admins@umich.edu>
> >Subject: Re: Serious Problems
> >Date: Wed, 7 Jun 2000 4:35 AM
> >
>
> > Hello,
> >
> > On Tue, Jun 06, 2000 at 06:23:39PM +0200, Michael Paesold wrote:
> >>
> >> 1) It appears that sometimes documents stored on the server (especially
> >> saved on the server) get corrupted in some way: with some files copied back
> >> to the mac, norton disk doctor (5.0) reports major problems, that can only
> >> be corrected by replacing the files with original ones. (But where to take
> >> originals from ?? :( )
> >
> >>From the backup :) I can't recall that this kind of thing has
> > been reported. Also, if possible, can you be more specific (what
> > kind of files or all kinds, any messages in logs, etc)?
> >
> >> 2) There are often problems with files, that can be opened with an app (e.g.
> >> quark xpress), can be saved, can be copied or moved on the server, but when
> >> you try to copy them to the macintosh, the operation will be canceled with
> >> error number -39.
> >
> > Some apps (qxp is one I think) keep files locked even after
> > closing them. Did you try to exit from the application and then
> > do the copy? I can't recall that people have had this problem.
> >
> >> 3) The most serious incident was that one:
> >> One user copied some files to a different location, than trashed a folder.
> >> Afterwards, he was unable to empty the trash, so he wanted to move the
> >> folder out of the trash again -> not possible. Then he tried to move some
> >> other files to the trash when suddenly the hole content of the parent folder
> >> disappeared. The trash can was empty now.
> >> The hole files were deleted. (Later, I couldn't find them on the server
> >> either)
> >> The only thing I found was that two macs were connected with the same
> >> user/passwd at the same time, nothing else.
> >
> > The Trash application needs some fiddling in order to get it to
> > work. It also depends on the netatalk's version. However, I'd
> > suggest that your users stay away from it, if possible.
> >
> >> The permission of all these files on the server volume are 660 owned by one
> >> user and group users. The server runs SuSE Linux 6.4/Kernel 2.2.14. netatalk
> >> version is netatalk-1.4b2+asun2.1.3 (SuSE default installation)
> >
> > I believe that there are many people still using successfully
> > netatalk 2.1.3, but I'd suggest moving to version 2.1.4-37b. It's
> > a prerelease but pretty stable. This one you'll have to compile
> > by yourself. Check out the archive--there are many messages with
> > instructions and, after all, it's not difficult to do it. If you
> > don't run any database apps (or similar which need byte-level
> > locking) then compile with -DUSE_FLOCK_LOCKS (put the def in
> > sys/linux/Makefile).
> >
> > Another thing: many problems are bound to a particular application
> > running on the Mac. The most notorious is definitely QXP. It
> > would be helpful if you include information about this as well.
> > And anything reported through syslog.
> >
> > Best regards,
> >
> > Dejan
> >
> You SUDO-UNIX people really shouldn't make grand statements about Mac
> Pre-press applications. Everything you have identified above is user
> privileges.
Perhaps you're right, but it was not described as such. Besides,
and to my surprise, I have seen many applications behave
differently in respect to AFP. Why do you say SUDO-UNIX? It
sounds odd.
> Try doing a chmod -R 777 on the entire shared volume and see if you still
> have the same problems. If they have gone away (as they did when I first
> started with Netatalk) them you can start a user & group plan of the server.
Doing this may be dangerous. That depends on the content of
course. Another obvious thing is that one may loose other
permission bits (like sticky for directories).
> When you make users, DO NOT make individual groups. That totally screws up a
> Mac workflow, because whoever touches a file is the only person how can
> touch it after that.
This is to general a statement. There are different security
needs.
Best regards,
Dejan
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:30:58 EST