NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
thom1
Sep 18, 2009Aspirant
afp connection rejected: (bad user/pass) afp log: "too many"
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:
The afp daemon log on 'turbot' (readynas NV+) as I'm being rejected from logging in:
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:
On the new NAS (turbot) the process descriptor looks like this:
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:
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:
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.
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.
16 Replies
Replies have been turned off for this discussion
- DrexsterAspirantCan 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. - jiminyAspirantJust 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. - DrexsterAspirantThanks 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! - jiminyAspirantSorry 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. - ncollingridgeAspirantThe 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.
- mikefortAspirantI 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?
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!