DSM-G600, DNS-3xx and NSA-220 Hack Forum

So after a lot of fighting with my DNS-323 (mainly because I went off and tried to compile 2.1.5 at one point, and didn't have a lot of the necessary packages installed), I finally got 2.2-beta4 installed and running; however, I still can't get Time Machine to work. I've seen comments on other threads that the Mac may have cached the capabilities of the network drive. Does anyone know if this is true, and if so, where they're stored?

While I'm posting, I wanted to share a couple of things that I overlooked during the process.

- I didn't have Berkeley 4.8 installed, but I believe it's required for builds of netatalk posted above. I found a package here: http://www.inreto.de/dns323/fun-plug/0. … 8.30-1.tgz

- I had followed these instructions when I first set up my 323. Uninstalling and reinstalling reset /ffp/start/afpd.sh and I had to re-modify it. I also found that I need to launch the cnid_server manually, which required adding "/ffp/sbin/cnid_metad" to the startup script as per the comments of that post.

I'm kind of hacking away via Google and trial and error, so if anyone has any tips or comments on what I've done, feel free to let me know if there's a way to improve my setup or knows how to get Time Machine running.

Frans wrote:

Any updates? Now that Lion is officially out I hope I can use my Timemachine again any time soon ...

The open letter linked above was updated this morning saying that netatalk 2.2.0 source will be posted shortly (it wasn't avail earlier today though... haven't checked since then though)...

Use the libcrypto from this post : http://dns323.kood.org/forum/viewtopic. … 298#p43298

Thanks for catching that. I had already installed rr-m's beta so I had his versions of libgpg and libgcrypt installed when I compiled 2.4.0. I did get it working, although it feels slow, at least for the first couple of backups. I know thebeck reported an issue earlier in this thread, but the link isn't working right now. The backup still completes, but it feels like it stalls at the end of the process. I'll have to double check later once I'm back at home, but how are people finding it on their setups?

Just went to http://sourceforge.net/tracker/?func=de … tid=108642 and noticed that the nasty performance issue has been officially marked as fixed in 2.2.0.

For those who have tested, did you upgrade and attempt to run Time Machine against a sparsebundle from a previous backup (and previous netatalk version)?  Or did you start with a new empty AFP share?

If you used an existing sparsebundle, I am wondering if there are some CNID considerations at play, especially since AFP 3.3 supports longer paths than prior versions (i.e., a different database structure).  If there happens to be some churn with the CNID backend, does it make more sense to start from scratch with a blank AFP share and create a new Time Machine backup?  This way we guarantee the CNID backend is created correctly.

Thoughts?

Did you just remove the sparsebundle?  Or all the content in the respective AFP share (including the hidden . files/folders)?  Or start with a fresh new empty folder?

I have not had time to start testing yet on my side, but hope to get to it next week or so.  Starting with a fresh new folder allows netatalk to recreate all the CNID stuff from scratch (assuming you are not using the -dbpath option) whiling keeping your old sparsebundle just in case.  In my past experiments, I have done the following steps to start from scratch (assuming the AFP share name is called backup):

1)  Stop netatalk
2)  cd /mnt/HD_a2
3)  mv backup backup.bak
4)  mkdir backup
5)  chmod 777 backup
6)  Start netatalk
7)  Run a brand new Time Machine backup over wired gigabit ethernet (for the first time)
8)  Go back to running Time Machine backups however you did it before (wireless, wired, whatever)
===== Time delay to confirm Time Machine and netatalk is working (usually days)
9)  rm -rf backup.bak


By moving the backup folder and recreating with the exact same name, your netatalk config will just work as-is when you restart netatalk.  And since we are running with the newer netatalk, you should not have to pre-create the sparsebundle as Time Machine should be able to create the sparsebundle directly.

Last edited by thebeck (2011-07-26 15:15:12)

We'll need a newer version of avahi for the publish to work.  The version of avahi (0.6.24) that currently comes with ffp is a little buggy.  The latest avahi 0.6.30 (http://www.avahi.org/) has all the support for a process to publish to it.  Perhaps fonz can compile 0.6.30 for us?

With that being said, you can manually configure avahi 0.6.24 to expose the netatalk server over zeroconf.  It may be a bit old, but check out this post for more information:  http://dns323.kood.org/forum/viewtopic.php?id=5735

Looks like 2.2.0 was released to sourceforge yesterday...
http://sourceforge.net/projects/netatal … atalk/2.2/

Release notes are here:
http://netatalk.sourceforge.net/2.2/Rel … 2.2.0.html

Perhaps Fonz can compile and add to the FFP repository?

I am a newbie to this, how do I go about compiling the newly released netatalk 2.2. Is there is place where this is documented for compiling the binaries to run on dns-323

Thanks

About the compiling, Fonz's package for compiling packages already contains the configuration to compile netatalk 2.1.3, and all I had to do is change the text in the version file to 2.2.0 and it worked!  It downloaded the source from Source Forge and all.  As rr-m mentioned, instructions on compiling fun_plug software are here:
http://nas-tweaks.net/106/compiling-sof … -fun_plug/
Since libcrypt and Berkeley DB48 are also a part of Fonz's build environment, everything builds fine without extra configuration.
I do get extremely slow connect times (about a minute or two), and during this time the DNS-323 CPU usage is at 100%.  The slow connect times seem to throw off Time Machine sometimes because it thinks the drive is unavailable.
P.S. amazing work Fonz!  Really appreciate it.

Last edited by techsmith (2011-08-02 17:15:09)

oldfeeling wrote:

Hi,
I followed all the instructions posted, but trying to mount my afp share on nas I get the error attached.
Tried to delete all .* folders on share, with no success.

Try rebuilding the whole DB for the affected share. You can do so issuing the command dbd -r -f volumepath. If you want to check the volume before, use dbd -s to see which errors come up.

The complete documentation for dbd can be found here: http://netatalk.sourceforge.net/2.2/htmldocs/dbd.1.html

oldfeeling wrote:

Hi,
I followed all the instructions posted, but trying to mount my afp share on nas I get the error attached.
Tried to delete all .* folders on share, with no success.

Any idea?

Thanks,
O

This error occurs because for some reason cnid_metad is not started automatically by 2.2.0 (at least for a lot of us that might be missing the same thing).  See post #27.