Thread
osx and netatalk on linux servers - solutions to prob?
I have been trying to resolve a solution with a linux box running 1.5.3.1 of netatalk.
The problem is when copying large folders of files to the shared volume from osx, it responds with an 'error -50' and stops the process. I've read a lot of people's possible solutions regarding recompiling with older methods of storing the directory data but it just seems like a patch.
Has anyone here had experience in resolving this issue in a 'real world' instance?
I'll be upgrading the software to 1.5.5 very soon, but don't know for certain whether this will solve the problem.
I've resorted to storing all our customer files on one mac and working from there. Not a good solution considering the backup only does the fileserver.
Any ideas?
The problem is when copying large folders of files to the shared volume from osx, it responds with an 'error -50' and stops the process. I've read a lot of people's possible solutions regarding recompiling with older methods of storing the directory data but it just seems like a patch.
Has anyone here had experience in resolving this issue in a 'real world' instance?
I'll be upgrading the software to 1.5.5 very soon, but don't know for certain whether this will solve the problem.
I've resorted to storing all our customer files on one mac and working from there. Not a good solution considering the backup only does the fileserver.
Any ideas?
Quote:
|
Originally posted by bluedog: I have been trying to resolve a solution with a linux box running 1.5.3.1 of netatalk. The problem is when copying large folders of files to the shared volume from osx, it responds with an 'error -50' and stops the process. I've read a lot of people's possible solutions regarding recompiling with older methods of storing the directory data but it just seems like a patch. Has anyone here had experience in resolving this issue in a 'real world' instance? I'll be upgrading the software to 1.5.5 very soon, but don't know for certain whether this will solve the problem. I've resorted to storing all our customer files on one mac and working from there. Not a good solution considering the backup only does the fileserver. Any ideas? |
Why don't you use TCP/IP rather than Appletalk?
Who said they were?
The Netatalk package is several parts: afpd, the file server; atalkd, the appletalk network stack; papd, the appletalk printing server; and a couple of other little things.
In any case, afpd supports both appletalk and TCP/IP connections. Without afpd, Linux cannot use AFP over any network protocol.
In any case, I'd try updating netatalk before anything else, and maybe check out the netatalk support on SourceForge.
tooki
The Netatalk package is several parts: afpd, the file server; atalkd, the appletalk network stack; papd, the appletalk printing server; and a couple of other little things.
In any case, afpd supports both appletalk and TCP/IP connections. Without afpd, Linux cannot use AFP over any network protocol.
In any case, I'd try updating netatalk before anything else, and maybe check out the netatalk support on SourceForge.
tooki
I've done both tcp and ddp services and while it seemed to be much better in OS9 when we started I'm not sure that the OSX file errors didn't cause future problems with OSX access to them.
The files themselves are intact and can be opened, but copying them back to the server causes the errors. I have set up netatalk prior to using osx on a few mac-based linux machines without a problem.
My work has a support vendor to handle the maintenance for our fileserver. I've asked that they update the software first. Then if that doesn't cut it to recompile the package with the option '--with-did=cnid' or '--with-did=last' as I've read in the sourceforge forum that these two options seem to work.
The kicker was an earlier version of netatalk seemed to work with OSX. I believe it was a 1.4 release and would have been around the time of OSX10.1.3 or so.
Anyhow, If anyone else has an idea please share. I'll post back when I have a working solution.
The files themselves are intact and can be opened, but copying them back to the server causes the errors. I have set up netatalk prior to using osx on a few mac-based linux machines without a problem.
My work has a support vendor to handle the maintenance for our fileserver. I've asked that they update the software first. Then if that doesn't cut it to recompile the package with the option '--with-did=cnid' or '--with-did=last' as I've read in the sourceforge forum that these two options seem to work.
The kicker was an earlier version of netatalk seemed to work with OSX. I believe it was a 1.4 release and would have been around the time of OSX10.1.3 or so.
Anyhow, If anyone else has an idea please share. I'll post back when I have a working solution.
Since Mac OS X ten has NFS capability why not add that to you linux box. In fact NFS may already be running on it.
Quote:
|
Originally posted by JRDasher: Since Mac OS X ten has NFS capability why not add that to you linux box. In fact NFS may already be running on it. |
Well, first I haven't tested NFS shares and don't know their useability in classic applications. Which was one initial reason to use netatalk, for allowing older software in classic to access the shares.
Previous to Jaguar, Some of my apps in classic didn't show the mounted volumes that showed up on the OSX desktop. I think it was resolved through Jaguar where I recently noticed the ability for the apps in question to see the volumes.
As for NFS, it is possible and I've heard of people using it. I'd like to try and maintain a consistent way to access the volumes though and have heard NFS and netatalk and Apple's own sharing protocols don't encode all their data in the same way (ie their resource forks and directory data).
Well, I've backpedalled and reverted to OS9 for access to our netatalk server.
Even after updating to their 1.5.5 version it has been giving us these problems of -50 errors.
Until I have a compelling reason to update and have confidence its working, I'll just stay in 9.
Its not the solution I wanted, but its better than no access to files.
Even after updating to their 1.5.5 version it has been giving us these problems of -50 errors.
Until I have a compelling reason to update and have confidence its working, I'll just stay in 9.
Its not the solution I wanted, but its better than no access to files.