afp connection rejected: (bad user/pass) afp log: "too many"

[thom1]

I just solved my own problem, but not without a lot of frustration and head-banging.

Here was the post I was writing (eg in the *present* tense) to describe the situation:

On my macbook pro, running OS X 10.5.8, every time it tries to log into my new ReadyNAS NV+:
I'm mostly trying command-K, "connect to Server"; no dice. "Invalid username or password."
Left sidebar sees it, but if I click on it, I get 'connection failed' or whatever.

Here is a log file from Console.app:

9/17/09 7:46:22 PM kernel ASP_TCP CancelOneRequest:  cancelling slot 1 error 89 reqID 2 flags 0x9 afpCmd 0x3F so 0x8c00000 
9/17/09 7:46:22 PM kernel ASP_TCP CancelOneRequest:  cancelling slot 1 error 89 reqID 2 flags 0x9 afpCmd 0x3F so 0x8c00000 
9/17/09 7:47:14 PM kernel ASP_TCP CancelOneRequest:  cancelling slot 1 error 89 reqID 2 flags 0x9 afpCmd 0x3F so 0x909a4c8 

The afp daemon log on 'turbot' (readynas NV+) as I'm being rejected from logging in:

turbot:/var/log# tail -f netatalk.log 
Sep 17 20:01:54 afpd[1277][server_child.c:390]: I:Default: server_child[1] 1308 exited 1
Sep 17 20:01:55 afpd[1310][dsi_tcp.c:208]: I:Default: ASIP session:548(6) from 192.168.1.70:50062(8)
Sep 17 20:01:55 afpd[1277][server_child.c:390]: I:Default: server_child[1] 1309 exited 1
Sep 17 20:01:55 afpd[1277][server_child.c:393]: I:Default: server_child[1] 1310 done
Sep 17 20:01:56 afpd[1277][server_child.c:390]: I:Default: server_child[1] 1312 exited 1
Sep 17 20:01:56 afpd[1313][dsi_tcp.c:208]: I:Default: ASIP session:548(6) from 192.168.1.70:50066(8)
Sep 17 20:01:56 afpd[1277][server_child.c:393]: I:Default: server_child[1] 1313 done
Sep 17 20:01:56 afpd[1314][dsi_tcp.c:208]: I:Default: ASIP session:548(6) from 192.168.1.70:50067(8)
Sep 17 20:01:56 afpd[1314][dsi_getsess.c:91]: I:Default: dsi_getsess: too many connections
Sep 17 20:01:56 afpd[1277][server_child.c:390]: I:Default: server_child[1] 1314 exited 1

I have an older NV+ to which I can do afp connections just fine. Both are running 4.1.6.

I can log into the new one (turbot) with CIFS with no problems.

I cannot log into the new NAS via afp with other user credentials on the NAS.
I cannot log into the new NAS via afp from other macs.

On the old NAS (specialdisk) the process descriptor looks like this:

root      1579  0.0  0.2  7840 2432 ?        S    Sep13   0:00 /usr/sbin/afpd -U uams_dhx.so,uams_clrtxt.so,uams_guest.so -c 50 -n specialdisk

On the new NAS (turbot) the process descriptor looks like this:

root      1277  0.0  0.2  7840 2432 ?        S    19:58   0:00 /usr/sbin/afpd -c -n

Oho.

(I have not made any changes to any config files yet; I'm just studying file contents.)

Hmm, looks like -c is the culprit. Looking further:

specialdisk:/etc/netatalk# tail -1 afpd.conf 
 - -uamlist uams_clrtxt.so,uams_dhx.so,uams_guest.so -nosavepassword -unixcodepage UTF8 -maccodepage MAC_ROMAN

turbot:/etc/netatalk# tail -1 afpd.conf 
 - -uamlist uams_clrtxt.so,uams_dhx.so,uams_guest.so -nosavepassword -unixcodepage UTF8 -maccodepage MAC_ROMAN

They look identical to me (same checksum), permissions look the same on the enclosing directories and on the conf files themselves, etc.

I feel like I'm not looking in the right place for the config, or that part of the conf is coming from somewhere else...

Let's look at /etc/init.d/netatalk: both files are identical in size, same checksum, same perms.

Oh wait, reading is fundamental, it references /etc/default/netatalk:

# Set defaults. Please change these options in /etc/default/netatalk.
AFPD_UAMLIST="-U uams_dhx.so,uams_clrtxt.so,uams_randnum.so"
AFPD_GUEST=nobody
AFPD_MAX_CLIENTS=50
ATALK_ZONE=
ATALK_NAME=`/bin/hostname --short`
ATALK_BGROUND=no

# Read in netatalk configuration.
if [ -f /etc/default/netatalk ]; then
  . /etc/default/netatalk
fi

And on my old one, that file has stuff in it. On the new one, it existed, but was empty.

Copied contents of one to the other, rebooted, it works wonderfully.

The new NAS came with 4.1.5 and I upgraded it to 4.1.6 right away, FWIW.

Maybe this post will help someone else out there who runs into the same problem.

[merlino73]

Hi,

I run in the same problem.

I can't get into the nas via AFP.

My /etc/default/netatalk is empty.

Can you post the content of the correct

/etc/default/netatalk

please?


Thank you
Massimiliano

[jameselee]

thom wrote:
I just solved my own problem, but not without a lot of frustration and head-banging. ... Maybe this post will help someone else out there who runs into the same problem.

@thom: Thank you very much: your post really helped me! I've been frustrated by the same problem for a while, and now it's solved.

That's really cool of you to take the time and post the solution.

@merlino73: I found that the following worked:

1. Use Frontview to stop AFP

2. ssh into your ReadyNAS

3. confirm that /etc/default/netatalk is empty - if not and you're having this same problem, you should definitely make a backup of the existing file before making any changes.

4. if /etc/default/netatalk is empty;

5. vi /etc/default/netatalk and paste in the text in the "Code" section below:



# Set defaults. Please change these options in /etc/default/netatalk.
AFPD_UAMLIST="-U uams_dhx.so,uams_clrtxt.so,uams_randnum.so"
AFPD_GUEST=nobody
AFPD_MAX_CLIENTS=50
ATALK_ZONE=
ATALK_NAME=`/bin/hostname --short`
ATALK_BGROUND=no



6. Use Frontview to start AFP - you should see your shares appear and they should be accessible.

Now, I doubt this is "officially supported", but it worked for me. Of course, you should know what you're doing if you're ssh'ing into your NAS.

I tested by shutting down AFP, creating an empty /etc/default/netatalk, starting AFP, and was back to the problem state. Following the procedure above restored AFP access to my ReadyNAS.

Thanks again, thom!!

[merlino73]

Thank you thom and jameselee.
I finally solved. 😄

Massimiliano

[Javerre]

Genius. I have been banging my head against this for hours.

My /etc/default/netatalk was also empty, and I could not connect over afp:// (for timemachine), so I followed your instructions, pasted the magic voodoo words into the empty file and voila! It now works like a charm.

No idea what has been zeroing out that file, though. This system used to work, and I've not messed with it until just now when my timemachine login failed. Something for the boys at Netgear to look into.

Anyway, Kudos to thom & jameselee!

BTW, I'm not clear why the defaults have to be here as well as in /etc/init.d/netatalk. But it works!

[raffuj]

Thank you. Thank you. Thank you!

I've been suffering with this since I upgraded to SL. I thought it was part of the AFP/SL/NV borkage. Never sat down to truly look at it but today for some reason I decided to start looking at the logs. Lo and behold I found my answer in less than 5 minutes.

Time machine is cranking away and everything is right with the world (at least for now).

[Tobermory]

Hi, I cannot connect to AFP all of a sudden either. These are the contents of my /etc/default/netatalk:

<Directory "/home/ftp/Toshiba">
  HideFiles none
  <Limit WRITE READ>
    Order deny,allow
    Allow from all
  </Limit>
  UserOwner root
  GroupOwner root
</Directory>

Is this normal?

Tahnks.

[sphardy1]

Tobermory wrote:
Hi, I cannot connect to AFP all of a sudden either. These are the contents of my /etc/default/netatalk: <Directory "/home/ftp/Toshiba"> HideFiles none <Limit WRITE READ> Order deny,allow Allow from all </Limit> UserOwner root GroupOwner root </Directory> Is this normal? Tahnks.

No - absolutely not. This is configuration data for the FTP server. Try the fix mentioned above

[Tobermory]

sphardy wrote:
Tobermory wrote: Hi, I cannot connect to AFP all of a sudden either. These are the contents of my /etc/default/netatalk: <Directory "/home/ftp/Toshiba"> HideFiles none <Limit WRITE READ> Order deny,allow Allow from all </Limit> UserOwner root GroupOwner root </Directory> Is this normal? Tahnks. No - absolutely not. This is configuration data for the FTP server. Try the fix mentioned above

Thankyou, that has resolved the problem and AFP is now working. I was unable to paste the # symbol into the file using vi and I got a comment at the bottom of the screen saying '# not implemented'. I understand this is just a comment line so deleted it.

All of these problems have appeared since I tried to add a new disk which turned out to have SMART issues. I have also recently opened up FTP access from the internet. Could any of these things have caused the errors and should I be aware of anything else - just in case?

Thanks for the support. Quicker than Netgear's response!

[sphardy1]

I really don't know what could cause this - the file you refer to is a system setup file for AFP access, is not typically user accessible, and should never be, or need to be, changed. So why it should be truncated/deleted/modified is a mystery to me. Even adding a hard disk should not cause this.

Needs the netgear dev's to investigate

[Tobermory]

Indeed. I have pointed them to this thread so hopefully they will take a look. Thanks again.

[Drexster]

Can someone please post step by step on how to modify do this?
I have very limited experience using terminal and don't want to further screw things up.


I'm unable to connect to a specific share using afp, cifs works fine however.
In front view, changing the share's afp default access to read/write only reverts back to disabled after hitting apply.

[jiminy]

Just want to say THANK YOU. I consider this advanced troubleshooting and if I didn't already work in unix for my work wouldn't have been able to do this...

For anyone trying to do this, here are some instructions for editing in vi: http://www.yolinux.com/TUTORIALS/LinuxT ... ed_vi.html
copying and pasting to make your backup (if your file wasn't empty - mine was not) are done using: http://www.tuxfiles.org/linuxhelp/fileman.html

Still I would never claim to "know what I was doing"...

The person who posted this solution absolutely rocks. You saved all my music in Itunes 10. Thanks again.

[Drexster]

Thanks for the links jiminy.

I figured out how to vi the file and edit it to match what was posted above.

However my afp access is still screwed up!
In frontview when looking at my list of shares one shows afp toggled and other not. Clicking the greyed out afp icon displays a panel with "Default Access" set to "Disabled", changing this to read/write and applying the settings results in the drop down reverting back to "Disabled"!.

This is really annoying since all/most my access is done through AFP for itunes and plex.
This is what happens in finder when i try to connect:
using connect to server "afp://10.0.1.134/media (media being the troubling share in question), i enter my name and password and then a window with the following appears:

"There was an error connecting to the server "10.0.1.134". Check the server name or IP address, and then try again.
If you are unable to resolve the problem contact your system administrator"


My other share "backup" works as expected with the same username/password.

Note, TimeMachine is currently able to mount it's share and backup files. A few weeks ago i used root ssh to delete my time machine backup files.

Help would be greatly appreciated!

[jiminy]

Sorry I can't help much - the solution posted here worked for me for the inability to log in - problem now is that without Bonjour Mounter I have to constantly restart the AFP service.

Automounting with the Bonjour Mounter may help you, the trial version?

In your share permissions, what about that about that box for "automatically set permissions" under AFP for Advanced AFP Permission, is it checked? Maybe you can put group and everyone to read/write at least temporarily and then it won't reset the default access to disabled each time. I think some of these issues may stem from ownership, which is an area I haven't ventured into fully understanding yet.

[ncollingridge]

The solution above worked for me as well when my ReadyNAS Duo stopped permitting AFP logons with otherwise valid credentials. Bit of a hassle, and I am annoyed that I had to go through a process that apparently invalidates software support in order to get my ReadyNAS going again.

[mikefort]

I am having issues with 4.2.18 on an Ultra 4.
I found this thread because it had "too many connections" in it.

I found in my afp.log:
Jul 22 12:17:00.529703 afpd[3130] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 172.28.15.8:60588
Jul 22 12:17:00.531937 afpd[2737] {main.c:185} (I:AFPDaemon): child[3130]: done
Jul 22 12:17:04.379595 afpd[3134] {dsi_tcp.c:212} (I:DSI): AFP/TCP session from 172.28.15.8:60589
Jul 22 12:17:04.379739 afpd[3134] {dsi_getsess.c:85} (I:DSI): dsi_getsess: too many connections
Jul 22 12:17:04.380824 afpd[2737] {main.c:183} (I:AFPDaemon): child[3134]: exited 1

I followed this advice and found my /etc/afpd.conf had the same stuff.
In looking at /etc/default/netatalk, the contents were nothing close to correct.
They look like DNS state.

search hsd1.my_isp.net.
nameserver 64.128.77.114
nameserver 64.128.72.114

I suspect there is a latent software bug that writes other configuration over this configuration file.
It might even be a problem in updating firmware, because I have been through a few of those too.

Does anyone know of a way to fix this file through normal Frontview actions?
I got the configuration from Frontview -> System -> Config Backup -> Backup.
I don't want to edit the file, then Restore without Tech Support blessing that.
Is there a way such as disabling AFP, then reenabling it? That didn't work 🙂

BTW, I also have issues with SMB, so is there a similar configuration file for that?