#461 Panic on copying/moving file within one share when destination filesystem differs (bind mount)


See summary.

When moving or copying a file within the same share with the destination folder having a different filesystem/bind-mount point on the server, afpd will panic and the share will be forcefully unmounted on the client (Finder error -36).


Oct 03 13:53:25.063509 afpd[16713] {fault.c:96} (S:Default): PANIC: ad_openat: cant chdir back
Oct 03 13:53:25.063980 afpd[16713] {fault.c:97} (S:Default): BACKTRACE: 11 stack frames:
Oct 03 13:53:25.064144 afpd[16713] {fault.c:103} (S:Default):  #0 /usr/lib/libatalk.so.2(netatalk_panic+0x1f) [0x7fa81267bccf]
Oct 03 13:53:25.064332 afpd[16713] {fault.c:103} (S:Default):  #1 /usr/lib/libatalk.so.2(ad_openat+0x128) [0x7fa81265f508]
    Oct 03 13:53:25.064452 afpd[16713] {fault.c:103} (S:Default):  #2 /usr/sbin/afpd(copyfile+0x69) [0x420709]
Oct 03 13:53:25.064569 afpd[16713] {fault.c:103} (S:Default):  #3 /usr/sbin/afpd() [0x416be4]
Oct 03 13:53:25.064718 afpd[16713] {fault.c:103} (S:Default):  #4 /usr/sbin/afpd(renamedir+0x139) [0x41a8d9]
Oct 03 13:53:25.064839 afpd[16713] {fault.c:103} (S:Default):  #5 /usr/sbin/afpd() [0x422dcf]
Oct 03 13:53:25.064972 afpd[16713] {fault.c:103} (S:Default):  #6 /usr/sbin/afpd(afp_moveandrename+0x1cd) [0x42321d]
Oct 03 13:53:25.065091 afpd[16713] {fault.c:103} (S:Default):  #7 /usr/sbin/afpd(afp_over_dsi+0x4d5) [0x40ded5]
Oct 03 13:53:25.065283 afpd[16713] {fault.c:103} (S:Default):  #8 /usr/sbin/afpd(main+0xbf8) [0x40bb38]
Oct 03 13:53:25.065430 afpd[16713] {fault.c:103} (S:Default):  #9 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fa810468ead]
Oct 03 13:53:25.065555 afpd[16713] {fault.c:103} (S:Default):  #10 /usr/sbin/afpd() [0x40bc85]
Oct 03 13:53:25.067318 afpd[6126] {main.c:184} (I:AFPDaemon): child[16713]: killed by signal 6


  • tscholak

    tscholak - 2013-07-06

    Problem still exists on netatalk 3.0.4. The file operation on the mac hangs and in the log on the linux server I see the following repeating over and over again every five seconds:

    Jul 06 00:59:32.218003 afpd[17994] {auth.c:587} (E:AFPDaemon): afp_disconnect: primary reconnect failed
    Jul 06 00:59:32.228853 afpd[17994] {fault.c:96} (S:Default): PANIC: ad_openat: cant chdir back
    Jul 06 00:59:32.228885 afpd[17994] {fault.c:97} (S:Default): BACKTRACE: 10 stack frames:
    Jul 06 00:59:32.228942 afpd[17994] {fault.c:103} (S:Default):  #0 /usr/lib64/libatalk.so.5(netatalk_panic+0x1f) [0x7ff159eb0a0f]
    Jul 06 00:59:32.229003 afpd[17994] {fault.c:103} (S:Default):  #1 /usr/lib64/libatalk.so.5(ad_openat+0x108) [0x7ff159e94368]
    Jul 06 00:59:32.229056 afpd[17994] {fault.c:103} (S:Default):  #2 /usr/sbin/afpd(copyfile+0x6c) [0x4213ec]
    Jul 06 00:59:32.229090 afpd[17994] {fault.c:103} (S:Default):  #3 /usr/sbin/afpd(renamefile+0x1f0) [0x421da0]
    Jul 06 00:59:32.229122 afpd[17994] {fault.c:103} (S:Default):  #4 /usr/sbin/afpd() [0x423e87]
    Jul 06 00:59:32.229153 afpd[17994] {fault.c:103} (S:Default):  #5 /usr/sbin/afpd(afp_moveandrename+0x1e3) [0x424163]
    Jul 06 00:59:32.229186 afpd[17994] {fault.c:103} (S:Default):  #6 /usr/sbin/afpd(afp_over_dsi+0x4ef) [0x40e68f]
    Jul 06 00:59:32.229219 afpd[17994] {fault.c:103} (S:Default):  #7 /usr/sbin/afpd(main+0xaa2) [0x40cbb2]
    Jul 06 00:59:32.229252 afpd[17994] {fault.c:103} (S:Default):  #8 /lib64/libc.so.6(__libc_start_main+0xed) [0x7ff15904160d]
    Jul 06 00:59:32.229285 afpd[17994] {fault.c:103} (S:Default):  #9 /usr/sbin/afpd() [0x40cc95]
    Jul 06 00:59:32.462903 afpd[17995] {auth.c:226} (N:AFPDaemon): AFP3.3 Login by tscholak
    Jul 06 00:59:32.492845 afpd[17995] {auth.c:554} (N:AFPDaemon): afp_disconnect: trying primary reconnect
    Jul 06 00:59:32.492908 afpd[17934] {server_child.c:233} (N:Default): Reconnect: no child[17994]
  • Nite

    Nite - 2013-08-18

    Can confirm this issue affects 2.1 & 3.0. Happens with separately mounted filesystems (ext4 in this case). Hangs iTunes indefinitely and seems to be related to several threads on iTunes hanging with afp shared library on various NAS products which use netatalk. I've been chasing this issue for 6+ mo and would appreciate if we can move this up in priority. Let me know what assistance I can provide.

    Here's the debug log:

    Aug 18 07:32:01.284225 afpd[7766] {cnid_dbd.c:625} (D5:CNID): cnid_dbd_get: DID: 7433, name: 'download.mp3'
    Aug 18 07:32:01.284343 afpd[7766] {cnid_dbd.c:642} (D5:CNID): cnid_dbd_get: got CNID: 7434
    Aug 18 07:32:01.284378 afpd[7766] {file.c:1129} (D5:AFPDaemon): renamefile: src[19, "download.mp3"] -> dst["download.mp3"]
    Aug 18 07:32:01.284391 afpd[7766] {file.c:1512} (D5:AFPDaemon): copyfile(sfd:19,s:'download.mp3',d:'download.mp3',n:'download.mp3')
    Aug 18 07:32:01.284403 afpd[7766] {ad_open.c:1723} (E:AFPDaemon): ad_openat: cant chdir back, exiting
    Aug 18 07:32:01.285081 afpd[7726] {main.c:214} (I:AFPDaemon): child[7766]: exited 3

    It's unfortunate that iTunes downloads the file as download.mp3 and then tries to move it into the dir stucture as the result with this bug is that mounting separate subdirs with netatalk and iTunes renders iTunes useless.

  • Ralph Böhme

    Ralph Böhme - 2013-08-18

    Please escalate via you NAS vendor. Several vendors have 3rd level support contracts with us (http://www.netafp.com/netatalk-support/).

    • masc

      masc - 2013-08-18

      it's not a vendor specific issue.

  • Nite

    Nite - 2013-08-19

    Correct, not a NAS issue. NAS was only highlighted to demonstrate that this problem is broader than the two who have reported it to date.

    Just confirmed 3.1-Beta1 suffers the same issue.

  • senh

    senh - 2013-09-11

    Same issue on Ubuntu 12.04.3 LTS & Netatalk 3.0.4 when moving a file/folder between EXT4 and ZFS filesystem mounts on the same AFP share.

    Copying between the mounts is working as expected.

    afpd[15539] {fault.c:96} (S:Default): PANIC: ad_openat: cant chdir back
    afpd[15539] {fault.c:97} (S:Default): BACKTRACE: 11 stack frames:
    afpd[15539] {fault.c:103} (S:Default):  #0 /usr/lib/libatalk.so.5(netatalk_panic+0x1f) [0x7f8c071d9dbf]
    afpd[15539] {fault.c:103} (S:Default):  #1 /usr/lib/libatalk.so.5(ad_openat+0x128) [0x7f8c071ba178]
    afpd[15539] {fault.c:103} (S:Default):  #2 /usr/sbin/afpd(copyfile+0x8b) [0x7f8c07661e7b]
    afpd[15539] {fault.c:103} (S:Default):  #3 /usr/sbin/afpd(+0x1670f) [0x7f8c0765770f]
    afpd[15539] {fault.c:103} (S:Default):  #4 /usr/sbin/afpd(renamedir+0x184) [0x7f8c0765b804]
    afpd[15539] {fault.c:103} (S:Default):  #5 /usr/sbin/afpd(+0x23a0a) [0x7f8c07664a0a]
    afpd[15539] {fault.c:103} (S:Default):  #6 /usr/sbin/afpd(afp_moveandrename+0x1ec) [0x7f8c07664e6c]
    afpd[15539] {fault.c:103} (S:Default):  #7 /usr/sbin/afpd(afp_over_dsi+0x3d7) [0x7f8c0764de57]
    afpd[15539] {fault.c:103} (S:Default):  #8 /usr/sbin/afpd(main+0xb3f) [0x7f8c0764b80f]
    afpd[15539] {fault.c:103} (S:Default):  #9 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f8c065c876d]
    afpd[15539] {fault.c:103} (S:Default):  #10 /usr/sbin/afpd(+0xa905) [0x7f8c0764b905]
    Last edit: senh 2013-09-11
  • Nite

    Nite - 2013-09-11

    This issue was initially opened almost a year ago. It is easily repeatable and demonstrated on multiple platforms. When will this issue get assigned and get looked at?

    I can provide test environments and support in demonstrating the issue.

    Would really like to see this nasty bug fixed. Not being able to move between mount points renders Netatalk almost useless.

    • Ralph Böhme

      Ralph Böhme - 2013-09-11

      Hey, it's open source, the code is readily available for any interested party. If you can't fix it yourself, find someone who's willing to spend at least several hours of his free time and fixes it for you.

  • Nite

    Nite - 2013-09-11

    As you know, bringing in a dev who has no expertise or experience on this project is more than a few hours... but hey, I understand that you aren't interested in fixing a small issue unless you are going to get paid.

    As I said, I am willing to provide support, testing, etc... IE my time and effort.

  • masc

    masc - 2014-02-10

    comment mentions, the fix relates to an issue occuring with "follow symlinks" enabled only.

    I don't have this option enabled, using bind mounts.

    so either the fix doesn't work or the comment is wrong )

  • masc

    masc - 2014-02-10

    however, I just verified against 3.1.0.. and it works. great!


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks