Yeah following Kim Culhan's recommendation, I've restored the dhx files to
the pam versions. But I still end up with the same permission problem and
errors in the logs.
[root@... pam.d]# ls -l /usr/lib64/atalk/
lrwxrwxrwx 1 root root 11 Jan 19 07:18 uams_clrtxt.so -> uams_pam.so
-rwxr-xr-x 1 root root 17128 Aug 19 00:25 uams_dhx2_pam.so
-rwxr-xr-x 1 root root 13000 Aug 19 00:25 uams_dhx2_passwd.so
lrwxrwxrwx 1 root root 16 Jan 21 10:47 uams_dhx2.so -> uams_dhx2_pam.so
-rwxr-xr-x 1 root root 16328 Aug 19 00:25 uams_dhx_pam.so
-rwxr-xr-x 1 root root 9512 Aug 19 00:25 uams_dhx_passwd.so
lrwxrwxrwx 1 root root 15 Jan 21 10:48 uams_dhx.so -> uams_dhx_pam.so
-rwxr-xr-x 1 root root 12048 Aug 19 00:25 uams_gss.so
-rwxr-xr-x 1 root root 6944 Aug 19 00:25 uams_guest.so
-rwxr-xr-x 1 root root 11352 Aug 19 00:25 uams_pam.so
-rwxr-xr-x 1 root root 9376 Aug 19 00:25 uams_passwd.so
-rwxr-xr-x 1 root root 12528 Aug 19 00:25 uams_randnum.so
Here is my /etc/pam.d/netatalk:
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
My afp_ldap.conf file has every line commented out with a #, which was the
I've stopped iptables to remove that as a possible problem.
Yes the username, uid, and gid are all the same on both the Fedora server
and Lion client. NFS works fine.
Any other things I can try?
On Sun, Jan 22, 2012 at 9:42 AM, Andrew Morgan <morgan@...> wrote:
> On Sat, 21 Jan 2012, Ryan Hoagland wrote:
> Hi good folks,
>> I'm at a dead end in getting a Netatalk service running correctly. It's
>> running and I can connect to it from my Lion Mac, but when I try to write
>> file to it, the Mac says I need to Authenticate and then says that I don't
>> have permission to write.
>> The logs are filled with
>> Jan 21 05:45:16 tequila afpd:
>> 9EA8F6545): no result from ldap_getnamefromuuid
>> Jan 21 05:45:16 tequila afpd: getnamefromuuid(uuid, &username,
>> failed: Resource temporarily unavailable
>> I was trying to avoid setting up a LDAP service because there isn't much
>> documentation on how to make that work with netatalk, so I've linked my
>> dhx.so files to the passwd versions hoping to avoid PAM.
>> -rwxr-xr-x 1 root root 17128 Aug 19 00:25 uams_dhx2_pam.so
>> -rwxr-xr-x 1 root root 13000 Aug 19 00:25 uams_dhx2_passwd.so
>> lrwxrwxrwx 1 root root 19 Jan 20 09:16 uams_dhx2.so ->
>> -rwxr-xr-x 1 root root 16328 Aug 19 00:25 uams_dhx_pam.so
>> -rwxr-xr-x 1 root root 9512 Aug 19 00:25 uams_dhx_passwd.so
>> lrwxrwxrwx 1 root root 18 Jan 20 09:16 uams_dhx.so ->
>> But I still get the getnamefromuuid failures. My configuration is pretty
>> vanilla: just creating some time machine shares.
>> [root@... netatalk]# rpm -q netatalk
>> :DEFAULT: options:upriv,usedots
>> /timemachines/RyanTM "RyanTM" options:tm
>> netatalk.conf is unchanged from the factory except for:
>> afpd.conf is factory, so it doesn't have any lines uncommented.
>> All the other config files are factory. afp_ldap.conf is all commented
>> So what's the simplest secret sauce to make Netatalk grant me write
>> privileges to my share? Do I really have to implement a LDAP server?
>> ports then will I need to open up in iptables to make that work? What
>> ports do I need to have open for Netatalk? I currently have all of these,
>> but there isn't good documentation to say what is really needed.
>> # AFP Netatalk
>> -A INPUT -m state --state NEW -m udp -p udp --dport 427 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 427 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 548 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 5353 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 201 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 202 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 204 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 206 -j ACCEPT
>> -A INPUT -m state --state NEW -m tcp -p tcp --dport 4700 -j ACCEPT
>> -A INPUT -m state --state NEW -m udp -p udp --dport 4700 -j ACCEPT
>> Thanks for the help,
> All Linux distributions that I know of use PAM, so you should be pointing
> your UAMs to PAM. Using PAM does not mean using LDAP. Your PAM
> configuration is stored in /etc/pam.d/<servicename>. Most of them point to
> the common-* files to use the system-wide PAM config.
> All you really need to run afpd is port 548 allowed.
> Are you connecting as a user that is present on your linux system?
> I'm not familiar with the FC16 package. Perhaps it has some unusual
> defaults that have LDAP lookups enabled? Do you have an afp_ldap.conf
> file? You probably want to remove it.