Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I'm trying to set up a couple of 323s for use with OS X. I'm not able to use smb (though it works fine), as I use odd characters in my filenames that afp can cope with. Having been through the process a half dozen times already and come to a grinding halt at various points, narrowly avoiding throwing the things out of the window, I thought it best to give it one last shot and make sure some people who know what they're doing (that's you) can tell me if what I'm doing is correct. Ultimately, should I be able to get these units working happily with OS X, I'll be documenting it fully and possibly going down the video route to demonstrate how it all works.
So, from scratch, here's my plan:
i) set disks up via webgui, 2x 500gb volumes, no RAID, just 'standard' configuration
ii) set up Telnet with basic fun_plug to get
iii) use downloadable etch image
vi) chroot to etch on 323
vii) set up afp
Is that about right, or am I missing anything?
Thanks in advance
Pete
Offline
That is about right. I have afp (netatalk) working with etch. I do have a small problem with character encoding. But this might be a netatalk configuration problem, I didn't really looked into it yet.
Offline
Thanks, krid. Appreciate your confirmation.
I've been on a roll all afternoon and now I've come unstuck - I was getting everything going on a NAT'd web-visible network (192.168.x.x) with a view to moving it to a non-NAT'd network (10.x.x.x) when it was all working. I have successfully installed and configured afp when things are on the 192.168.x.x network - can log in, copy files, move files, save files, and so forth - no problem there - and I thought I'd nailed the problem and could breathe a sigh of relief. Turns out, when I moved it to the 10.x.x.x network, afp stops working. I can ping the device, the webgui is viewable, afpd is running - but no dice, can't access or connect via afp:// in Finder. Am I doing something wrong?
Offline
OK, some more findings: I rebuilt from scratch without moving networks - afp works perfectly when I follow the instructions on the wiki, restart the unit for sanity checks, telnet in, chroot into etch manually, start afpd via command line (no errors - pid is present) - still can't connect from OS X via Finder. IPs haven't changed, network is the same, afpd is running, no connections allowed
Offline
Can you ping the mac from the dns-323? I have afp working, but that is all I know about it. I had bonjour working too, but for some unknown reason that doesn't work anymore.
I guess your problem is not with afp but with the changed ip number. Did you use /etc/hosts maybe?
Offline
krid wrote:
Can you ping the mac from the dns-323? I have afp working, but that is all I know about it. I had bonjour working too, but for some unknown reason that doesn't work anymore.
I guess your problem is not with afp but with the changed ip number. Did you use /etc/hosts maybe?
Hey krid, thanks again for your response. I don't use /etc/hosts at all - no name mapping, just pure IP addresses until I get the bugs ironed out
I've taken a look today with a fresh pair of eyes:
i) I can telnet to the DNS-323 from my Mac (10.1.1.1 -> 10.1.1.101)
ii) I can ping the DNS-323 from my Mac (10.1.1.1 -> 10.1.1.101)
iii) I can ping the DNS-323 from my Mac when etch is running - (10.1.1.1 -> 10.1.1.101)
iv) I can ping my Mac from the DNS-323 when telnet'd in (10.1.1.101 -> 10.1.1.1)
iv) I can ping my Mac from the DNS-323 when chroot'd in etch (10.1.1.101 -> 10.1.1.1)
v) I can ping my Mac from the DNS-323 when chroot'd in etch with afpd running (10.1.1.101 -> 10.1.1.1)
vi) I can connect via smb:// from my Mac (10.1.1.1 -> 10.1.1.101)
So, I'm now in a position that, having repeatedly built the boxes according to instructions, afpd is running and all appears to be tip-top, only to be given an error when connecting via Finder using afp:// - specifically:
The Finder cannot complete the operation because some data in "afp://10.1.1.101" could not be read or written. (Error code -36)
Manual mounting from Terminal, explicitly passing the username and password, gives this error:
mount_afp: AFPMountURL returned error 22, errno is 2
which I'm investigating at the moment.
I will persevere
Offline
OK, some interesting progress - I set the authentication method to cleartext for debugging, now I attempt to connect from Finder to the DNS-323...and get as far as the login box for username/password...but it won't accept my password, even though I know it's correct. It then gives a new error (for my collection):
Sorry, the operation could not be completed because an unexpected error occurred. (Error code -5002)
Another interesting side-effect is when I try to su to my newly created user in the chroot'd Debian, it freaks out with pages and pages of:
bash: /dev/null: Permission denied bash: /dev/null: Permission denied bash: /dev/null: Permission denied bash: /dev/null: Permission denied
Any ideas anyone? Thanks in advance!
bash: /dev/null: Permission denied
Last edited by gaekwad (2007-12-17 20:29:57)
Offline
I think that error could be telling you that /dev/null needs write permissions
see: http://dns323.kood.org/forum/p4238-2007 … html#p4238
Offline
You may already know this, but:
The stock Netatalk for debian does not support encrypted password authentication -- only cleartext. Leopard, on the other hand, will not use cleartext and insists on encrypted passwords, so a Leopard client cannot connect to the standard Debian distribution of netatalk.
See the wiki for instructions on building netatalk with encryption enabled. Pay particular attention to making sure that uams_dhx.so appears within the uamlist for your server. For example, the last line of my /etc/netatalk/afpd.conf looks like this.
- -tcp -noddp -noslp -uamlist uams_clrtxt.so,uams_dhx.so -nosavepassword
As for your /dev/null problem, see the link in the previous post; I have run into the same problem and fixed it as the previous poster suggested.
Last edited by ChrisOwens (2007-12-18 23:11:16)
Offline