Subject: Error type -50 while copying files to netatalk server (4.1b2+2.13)

From: Rich Winkel <[email-masked]>
Date: Wed, 6 Sep 2000 11:50:00 -0500 (CDT)

Whenever I try to copy a file to a netatalk volume it gives a
"cannot be written because an error of type -50 occurred".
Looking in the (freebsd 3.4-stable) logs, I see that the
message
afp_openfork: ad_open: Permission denied
appears sometimes, but not all the time when this happens.

I can see that the file gets copied sucessfully, in fact
if I ignore the error prompt, go to another mac and open the folder
I can copy or run the file with no problem, but once I answer
"stop" or "continue" in the error dialog box, the file is deleted.
Does anyone have any ideas?

Hopefully,
Rich

---

From: "Marc J. Miller" <[email-masked]>
Date: Wed, 6 Sep 2000 18:50:57 -0700

I've seen this in netatalk 1.5 and thought maybe one of the recent patches
had a problem, but if you saw it in 1.4b2+2.1.3, then I guess it's a little
bit deeper.  I'm not a Mac guru, but I'm told that error -50 is a signal of
memory problems.  It's similar to a Linux "Segmentation Fault" when a
program tries to read/write outside its designated envelope.  It's hard to
say whether it's being caused by netatalk or by MacOS, but usually a reboot
fixes that problem for days on my MacOS test machine.

---

From: Dan Horth <[email-masked]>
Date: Thu, 7 Sep 2000 13:15:16 +1100

you have a permissions problem in the volume being shared... try "ls 
-lt" on the directory that netatalk is sharing and check to see 
what's going on. you should make sure that the vollume is owned and 
grouped in such a way that your clients have access and that the 
permissions are set something like "chmod -R 2770 ./netatalkshare" 
which will give your users full read and write access and will cause 
files created by them on the share to inherit the permissions set up 
in the parent directory.

make sure that you have checked the permissions of the hidden 
(.AppleDouble and .AppleDesktop) type files - by what you're 
describing I'd say your .AppleDouble is not accessable by your 
netatalk user - just a guess... :)

HTH - dan.

-- 

	Nitro - 3D Visualisation, Graphics & Animation
		Ph (+61 2) 9810 5177 - Fx (+61 2) 9810 0199
			http://www.nitro.com.au/

---

From: Rich Winkel <[email-masked]>
Date: Thu, 7 Sep 2000 12:14:40 -0500 (CDT)

Many thanks to all who responded!  The fix I applied is appended at bottom,
since it seems at least one other person needs it.

Now I have one last obstacle to getting this in production: it
won't authorize passwords on nfs-mounted disks.

The relevant fstab entries are:
/dev/da1s1e             /mac            ufs     rw,suiddir      2       2
grok:/home/grok         /home/grok      nfs     rw,suiddir      0       0

I can login to home dirs on /mac, but when I attempt to login to a
dir on /home/grok, the password is rejected as incorrect and I get
"Failed to open /home/grok/rw/.passwd" in the syslog.
In both cases the .passwd file exists in the home dir and has
-rw------- permissions.  The password is in plain text.
afpd.conf sez:
"Holmes" -nocleartxt -randnum -rand2num -guest -guestname nobody

On another issue, will the suiddir attribute work via nfs if root is
mapped to nobody on the nfs server?  Could this be related to the
.passwd problem?  (I can't remount /home/grok at the moment)

Many thanks for this wonderful software and list!

Rich

Date: Wed, 6 Sep 2000 11:21:56 -0600 (MDT)
From: Tim Carlson <[email-masked]>
To: Rich Winkel <[email-masked]>
Subject: Re: Error type -50 while copying files to netatalk server (4.1b2+2.13)

> Does anyone have any ideas?

Permissions problem. Here is how I fixed it.
----------------------------------------------------------------------
This error can occur when you are trying to copy a file from a Mac to a
netatalk share. The reason for the error is that afpd wants to create an
icon for the file type in the top level .AppleDesktop directory. If this
direcotry is not writeable by the user, you get this error. What made it
hard for me to trouble shoot was that the error doesn't occur all of the
time. If the icon already exists, then of course you don't get the error.
 
The easiest thing to do (yes you can do all kinds of fancy thinks with
"set gid" but this is easy) is:
 
su
cd .AppleDesktop
mkdir a b c d e f g h i j k l m n o p q r s t u v w x y z
mkdir A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
chmod 777 *
 
Tim

---

From: "Marc J. Miller" <[email-masked]>
Date: Thu, 7 Sep 2000 11:09:41 -0700

Okay... does this mean that users have to have permission to write to the
MacOS desktop in order to write a file to the server of an unknown type?  (I
don't want that...)

---

From: Tim Carlson <[email-masked]>
Date: Thu, 7 Sep 2000 12:20:59 -0600 (MDT)

> MacOS desktop in order to write a file to the server of an unknown type?  (I

The .AppleDesktop directory on the UNIX side doesn't have anything to do
with the "Desktop Folder" Odd.. but true :)

Tim

---

From: Rich Winkel <[email-masked]>
Date: Fri, 8 Sep 2000 10:01:08 -0500 (CDT)

> .passwd problem?  (I can't remount /home/grok at the moment)

I take it the problem is the "nobody" mapping on the nfs server.
The .passwd file is probably checked as root.
Argh!!!

Rich