• AFP Not working since upgrade to 6.6.7


    mhorn
    • Annoyance

    The release notes show that only docker changed from 6.6.6 to 6.6.7, but AFP hasn't worked for me since the upgrade.

    Mar 23 15:35:26 Tower emhttpd: req (5): shareName=media&shareExportAFP=e&shareVoldbpathAFP=&shareSecurityAFP=secure&changeShareSecurityAFP=Apply&csrf_token=****************
    Mar 23 15:35:26 Tower emhttpd: Starting services...
    Mar 23 15:35:34 Tower afpd[25355]: ===============================================================
    Mar 23 15:35:34 Tower afpd[25355]: INTERNAL ERROR: Signal 11 in pid 25355 (3.1.11)
    Mar 23 15:35:34 Tower afpd[25355]: ===============================================================
    Mar 23 15:35:34 Tower afpd[25355]: PANIC: internal error
    Mar 23 15:35:34 Tower afpd[25355]: BACKTRACE: 12 stack frames:
    Mar 23 15:35:34 Tower afpd[25355]: #0 /usr/lib64/libatalk.so.18(netatalk_panic+0x22) [0x1476e1fd9c92]
    Mar 23 15:35:34 Tower afpd[25355]: #1 /usr/lib64/libatalk.so.18(+0x40dbc) [0x1476e1fd9dbc]
    Mar 23 15:35:34 Tower afpd[25355]: #2 /lib64/libc.so.6(+0x407d0) [0x1476e12227d0]
    Mar 23 15:35:34 Tower afpd[25355]: #3 /lib64/libc.so.6(__libc_malloc+0x1a6) [0x1476e1275bd6]
    Mar 23 15:35:34 Tower afpd[25355]: #4 /usr/lib64/libatalk.so.18(+0x2a85f) [0x1476e1fc385f]
    Mar 23 15:35:34 Tower afpd[25355]: #5 /usr/lib64/libatalk.so.18(atalkdict_set+0x189) [0x1476e1fc3ca9]
    Mar 23 15:35:34 Tower afpd[25355]: #6 /usr/lib64/libatalk.so.18(atalk_iniparser_load+0x585) [0x1476e1fc4ac5]
    Mar 23 15:35:34 Tower afpd[25355]: #7 /usr/lib64/libatalk.so.18(load_volumes+0x142) [0x1476e1fddbf2]
    Mar 23 15:35:34 Tower afpd[25355]: #8 /usr/sbin/afpd(afp_over_dsi+0x29b) [0x40c9bb]
    Mar 23 15:35:34 Tower afpd[25355]: #9 /usr/sbin/afpd(main+0xa55) [0x40ac05]
    Mar 23 15:35:34 Tower afpd[25355]: #10 /lib64/libc.so.6(__libc_start_main+0xeb) [0x1476e12060ab]
    Mar 23 15:35:34 Tower afpd[25355]: #11 /usr/sbin/afpd(_start+0x2a) [0x40ae9a]
    Mar 23 15:35:34 Tower afpd[2414]: child[25355]: asev_del_fd: 5
    Mar 23 15:35:40 Tower afpd[26981]: afp_disconnect: primary reconnect failed

     

    I've restarted multiple time, but none of my AFP shares are showing up.

    I also see no shares available on the Disk Shares even though all of the shares have AFP enabled.

     

    Searching the forums for 'AFP' results in nothing found.

     

     




    User Feedback

    Recommended Comments

    This is the proper forum to request support?  Or does purchasing the upgraded license ensure any level of support? With no AFP share working, this was an expensive experiment which is now failing.  

     

    Link to comment
    5 hours ago, mhorn said:

    This is the proper forum to request support?  Or does purchasing the upgraded license ensure any level of support? With no AFP share working, this was an expensive experiment which is now failing.  

     

    forum support is by community members although Limetech staff do occasionally drop in and provide advice.   You should never assume, though, that Limetech staff will necessarily see problems raised on the forum.  On the whole the forum advice is good but it does depend on the exact experience of the particular forum members.    The normal formal route is via email to Limetech (contact details at bottom of forum pages), and as far as I know the type of license you have is not relevant.  Limetech also provide paid hands-on support at an hourly rate but that is probably more expensive than you want to go.

    Edited by itimpi
    Link to comment
    4 hours ago, jonathanm said:

    Restart in safe mode and see if that makes any difference.

    Restarted in safe mode, started the array, but I still do not see any of the shares from a client under AFP. :(

     

    I don't see any errors in the logs.

     

    One strange thing is that when I try some of the AFP commands to get info python and perl don't seem to be there:

    Quote

    root@Tower:/var/log# afpstats
    /usr/bin/env: ‘python’: No such file or directory
    root@Tower:/var/log# macusers
    -bash: /usr/bin/macusers: /usr/bin/perl: bad interpreter: No such file or directory
    root@Tower:/var/log# asip-status.pl
    -bash: /usr/bin/asip-status.pl: /usr/bin/perl: bad interpreter: No such file or directory
    root@Tower:/var/log#

    Is that expected?  Or maybe due to safe mode?

     

    Link to comment

    Perl and Python are not part of the standard Unraid install.   They can be installed via the Nerd Pack plugin but if you are running in Safe Mode then all plugins are disabled.

    Link to comment

    After finally getting some time to test this more, the problem seems to stem from my Mac(s) having network connections to two different subnets.

     

    If I have both a wired connection and a wireless connection, which are on different subnets due to a Google WiFi managing wireless and my Linksys managing wired, then I can not access the unRAID NAS which is only on the wired network.

     

    My ReadyNAS AFP shares can be seen on my Mac regardless if I have either wired, wireless, or both active.

     

    When I move the UNRAID to the wireless network, then my Mac could only see the UNRAID when only the wireless was active.

     

    As I have two network ports in the UNRAID, I'm working around the issue for now by having a direct connection to both subnets which seem to avoid the problem.

     

    My ReadyNAS didn't have any such problems, and I don't see anything special setup for the ReadyNAS in my router. 

     

    I don't see any setting on the UNRAID system for AFP accept enable or disable.

    Can UNRAID not share AFP across a router?

     

    Link to comment
    1 hour ago, mhorn said:

    Can UNRAID not share AFP across a router?

    That would need to be configured in the router.

    Link to comment

    But I have to wonder why I don't have to configure the router for my ReadyNAS to properly work; why does one work and not unRAID.

    Link to comment

    Both the ReadyNAS and the unRAID were connected to SubnetA.

     

    When my Mac is connected to only SubnetA:

    -- both ReadyNAS and unRAID can use TimeMachine and visible shares in Finder

     

    When my Mac is connected to only SubnetB:

    -- ReadyNAS can use TimeMachine and visible shares in Finder

    -- unRAID not working

     

    When my mac is connected to both SubnetA and SubnetB:

    -- ReadyNAS can use TimeMachine and visible shares in Finder

    -- unRAID could use TimeMachine (most of the time), but no visible shares in Finder -- fails to connect

     

     

    Now that I have also connected the unRAID directly to SubnetA and SubnetB, both TimeMachine and visible shares in Finder work when my Mac is also connected to both Subnets.

     

    Link to comment

    While you can physically connect two different subnets to the mac, It's my understanding that the mac isn't actually using both at the same time. This is a little outside my zone, so I may be wrong, but I believe that the mac will use the networks in the order that you have set in system prefs>networks.

    Link to comment

    Is anyone having issues with trying to backup using smb Enhanced macOS interoperability? The backup will starts and then it stops after maybe 3 minutes. Anyone experiencing the same issue or can help me?

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.