The latest version of netatalk is 2.1.2 the version in slackware 13.1 is 2.0.4.  So I want to build the new version for unraid.  Should I build it on slackware or build it on the flash boot drive for unraid?  I tried building it on the flash drive and installed gcc and glibc then rebooted and the kernel crashed.  Thx,

Kyle

The latest version of netatalk is 2.1.2 the version in slackware 13.1 is 2.0.4.  So I want to build the new version for unraid.  Should I build it on slackware or build it on the flash boot drive for unraid?  I tried building it on the flash drive and installed gcc and glibc then rebooted and the kernel crashed.  Thx,

Kyle

The version in Slackware-current is netatalk-2.0.5.  What particular "improvements" are you looking for?

 

I have three macs backing up to the unraid.  It works about 60% of the time, other times, the backup goes on forever and I have to restart it.  Also I tried coping a Terabyte drive to the unRaid and it failes with the odd error.  I was hoping the latest version of netatalk would fix some of these issues.

 

M-

Here's the change logs of the releases from 2.0.5 upto 2.1.2.

 

Netatalk 2.1.2 is a minor update highlighting the following new features and changes:

    * afpd: fix for possible crash in case more then one server is configured in afpd.conf.

    * afpd: ExtendedAttributes in FreeBSD did not work.

 

Changes in 2.1.2

    * FIX: afpd: fix for possible crash in case more then one server is configured in afpd.conf.

    * FIX: afpd: ExtendedAttributes in FreeBSD

    * FIX: afpd: sharing home folders corrupted the per volume umask.

    * UPD: afpd: umask for home folders is no longer taken from startup umask.

    * UPD: afpd: dont and permissions with parent folder when creating new directories on "upriv" volumes.

    * UPD: afpd: use 'afpserver@fqdn' instead of 'afpserver/fqdn@realm'. Prevents a crash in older GNU GSSAPI libs on eg. CentOS 5.x.

 

Netatalk 2.1.1 is a minor update highlighting the following new features and changes:

    * afpd: fallback to a temporary in memory tdb CNID database if the volume database can't be opened now works with the default backend "dbd" too.

 

Changes in 2.1.1

    * UPD: fallback to a temporary in memory tdb CNID database if the volume database can't be opened now works with the default backend "dbd" too.

    * FIX: afpd: afp_ldap.conf was missing from tarball. This only effected [Open]Solaris.

    * FIX: afpd: Check if options->server is set in set_signature, preventing SIGSEGV.

    * FIX: afpd: server signature wasn't initialized in some cases

    * FIX: DESTDIR support: DESTDIR was expanded twice

    * FIX: Fix for compilation error if header files of an older Netatalk version are installed.

 

Netatalk 2.1 is a minor upgrade highlighting the following new features and changes:

 

Protocol level:

    * AFP 3.2

    * IPv6

    * Extended Attributes support

    * ACL support with ZFS

    * AppleTalk support in afpd and AppleTalk daemons (atalkd and papd) are disabled by default

 

afpd:

    * default CNID backend is "dbd"

    * enable live debugging with SIGINT

    * afpd uses an in memory temporary DB if can't open the volume's database, but currently this only works with the "cdb" or "tdb" backends not with the default "dbd".

 

atalkd:

    * atalkd: workaround for broken Linux 2.6 AT kernel module: Linux 2.6 sends broadcast queries to the first available socket which is in our case the last configured one. atalkd now tries to find the right one. Note: now a misconfigured or plugged router can broadcast a wrong route !

 

Tools:

    * dbd: "dbd" CNID database and volume maintanance and intergrity check utility

    * apple_dump: dump AppleDouble files

Protocol level:

    * AFP 3.2

    * IPv6

    * Extended Attributes support

    * ACL support with ZFS

    * AppleTalk support in afpd and AppleTalk daemons (atalkd and papd) are disabled by default

 

AFP 3.2 could help since the macs are running snow leopard.

Protocol level:

    * AFP 3.2

    * IPv6

    * Extended Attributes support

    * ACL support with ZFS

    * AppleTalk support in afpd and AppleTalk daemons (atalkd and papd) are disabled by default

 

AFP 3.2 could help since the macs are running snow leopard.

Many people are running snow leopard, and are using netatalk-2.0.5 without any problems.

And, do you really require IPv6?

 

Anyway, I got my "netatalk.SlackBuild" script from last time, and tried running it on the 2.1.2 tarball....

It complained about many things and aborted.  I have no means to investigate the matter any further.

 

What I was getting at earlier was that -- unless there is a very speciffic and very desirable feature (like it was the case with the time-machine support) -- I wouldn't advise anybody to go past "Slackware-current".  Changelogs show you what's been fixed, but they don't show you what's been broken in the process.  The Slackware people have always been nicely conservative about which versions of various programs are stable enough to be included. 

 

I am running 2.0.4 and will upgrade to 2.0.5.  Are the people using snow leopard exporting the "disk1" instead of the share?

thx

M-

I am running 2.0.4 and will upgrade to 2.0.5.  Are the people using snow leopard exporting the "disk1" instead of the share?

thx

M-

 

Yes, and that will not change. This is due to the way unRAID works and has nothing to do with AFP. Until Tom makes some radical changes in unRAID, exporting user shares will never work reliably.

I assume that if "disk1" is part of the share, the data written to it will be backed up via the unraid parity algorithm even though we are not writing to the share.... right?

Thx

M-

I assume that if "disk1" is part of the share, the data written to it will be backed up via the unraid parity algorithm even though we are not writing to the share.... right?

Thx

M-

correct.  Writing to /mnt/disk1 will update parity.

 

The term "backed up" is incorrect however... data is not "backed up" with parity, ever, for any data. 

 

Parity is a calculated value that when used in combination with every other disk on your server can be use to deduce the value of a single missing or failed disk.

 

Pretend every disk on your server is only one bit in size.  Pretend each hard disk can hold either a single 1 or 0.

 

Now, load all the data disks with a "1" or "0" as you like.  Now... add up all the "1s" and if an EVEN number, put a "0" in the parity disk.  If an ODD number, put a "1" in the parity disk. 

 

Once you do that you will have an even number of "1s" across all the data disks and parity disk. 

 

Lastly, at random, pretend you cannot read a bit in a single disk.  Now, if you read ALL the other disks, and they have an odd number of "1s", then the bit you cannot read must have also been a "1" so the total number of "1s" will be even.  In the same way, if the disks you could read had a even number of "1s," the disk you could not read had to have had a "0," so you would still have an even number of "1s"

 

You do not "back up" your files to the parity disk... you simple store a set of "even parity" bits just like the single bit I used in my example.  By themselves, they are useless.  In combination with the data disks, they can be used to deduce a single missing disk.

 

Joe L.

Thx I understand the parity algorithm for producing a redundant copy of a bit.  The only issue I am seeing with the netatalk and avahi is that the disks do not spin down.

Cheers.

Okay I have been running unraid 4.5 with nettalk 2.0.5 for about a year now.  I have three MACs backing up to it.  The backups work ok.  I currently am attempting a restore and get a couple of problems.  When I try and restore using Disk Utility I get "resource unavailable" errors.  If I run the migration assistant, it restores for about an hour and then stops.... the network traffic drops from about 50MBps to 0 and I see AFP "Tickle" packets going back and forth. I am running Snow Leopard 10.6.5.

M-