Bus Error when mounting Netatalk shares

[paws]

I've got System 7.6.1 on a Quadra 700. OT 1.3.1 and AppleShare 3.8.3 (latest as per System 7 Today).

Netatalk 4.4.2 on x86 Arch Linux with AppleTalk enabled. I can share a CUPS printer and print, but when I try to mount an AFP share, the Mac crashes with a bus error. I can log in, see the list of shares, select on to connect, but then it crashes. Netatalk reports that I've logged in.

Any ideas on how to troubleshoot? Adding/removing legacy volume size makes no difference. I've tried both randnum and dhx.

SQLite is because dbd didn't work at all for me! On connection it would time out.

I have used this volume with an older version of Netatalk to speak to an OS 9 machine, but I deleted the .AppleDB folder.

$ cat /etc/afp.conf
;
; Netatalk AFP file server configuration file
;
; See the `afp.conf' manual page for all available options
;

[Global]
; Global server settings
afp interfaces = enp2s0
appletalk = yes
uam list = uams_randnum.so

[Homes]
basedir regex = /home
path = afpshare
cnid scheme = sqlite
legacy volume size = yes

$ cat /etc/atalkd.conf
#
# AppleTalk daemon (atalkd) configuration file
# Part of the Netatalk suite
#
# Leave this file empty to allow atalkd to detect and configure
# AppleTalk interfaces automatically
#
# See the `atalkd.conf' manual page for all available options
enp2s0 -phase 2 -net 0-65534 -addr 65280.13

 

[NJRoadfan]

add the line legacy icon = sdcard under the Global section. One of the ASC revisions has a bug in it that causes a crash if no icon data is received. Remove the afp interfaces and legacy volume size option too. I don't think you can use the "path" option under the special Homes share. I would setup a dedicated folder if you want a special AFP mount point.

 

[paws]

Adding the icon worked! Thanks a lot. Now I have file sharing. Cool.

 

[slipperygrey]

minor correction: "path" is indeed a legal option for the [Homes] section and will lead to this subdir being shared instead of the root of each user's home dir -- I leverage this option frequently since it's arguably preferable to sharing your entire home dir

Ref. https://netatalk.io/manual/en/afp.conf.5#the-homes-section

Edit: added this trick to the Netatalk Troubleshooting guide

 

[paws]

Ah, very cool, I meant to see if I could get in touch with you to add it to the documentation.

I don't log in to Github anymore, so I can't add this, but as stated, I also had trouble with the default CNID backend. Here's a snippet of what my logs looked like before I switched to the sqlite scheme. The Mac would just hang and then give some generic error, I can't remember the wording (and I'd rather not switch back since I don't really understand what CNID is - but the docs make it sound like that'll wreak havoc on my files somehow?)

May 15 00:58:58 pond netatalk[786889]: Netatalk AFP server starting
May 15 00:58:58 pond systemd[1]: Started Netatalk AFP fileserver for Macintosh clients.
May 15 00:58:58 pond netatalk[786889]: Registered with Zeroconf
May 15 00:58:58 pond cnid_metad[786893]: CNID Server listening on localhost:4700
May 15 00:59:04 pond afpd[786891]: pond:AFPServer@* started on 65280.13:129 (4.4.2)
May 15 00:59:04 pond afpd[786891]: Netatalk AFP/TCP listening on interface enp2s0 with address 10.0.1.175:548
May 15 00:59:04 pond afpd[786891]: Netatalk AFP/TCP listening on interface enp2s0 with address XXXXXX
May 15 00:59:04 pond afpd[786891]: Netatalk AFP/TCP listening on interface enp2s0 with address XXXXXX
May 15 00:59:04 pond afpd[786891]: Netatalk AFP/TCP listening on interface enp2s0 with address XXXXXX
May 15 01:08:11 pond afpd[787267]: pam_unix(netatalk:session): session opened for user aduck(uid=1000) by (uid=0)
May 15 01:08:11 pond afpd[787267]: Login by aduck (AFP2.2)
May 15 01:08:12 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:12 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:13 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:14 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:15 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:16 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:17 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:18 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:19 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:20 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:21 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:22 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:23 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:24 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:25 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:26 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:27 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:28 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:29 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:30 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:31 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:32 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:33 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:33 pond afpd[787267]: transmit: Request to dbd daemon (volume aduck's home) timed out.
May 15 01:08:33 pond afpd[787267]: afp_openvol(/home/aduck/afpshare): Fatal error: Unable to get stamp value from CNID backend
May 15 01:08:41 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:41 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:42 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:43 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:44 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:45 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:46 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:47 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:48 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:49 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:50 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:51 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:52 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:53 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:54 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:55 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:56 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:57 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:58 pond afpd[787267]: read: Connection reset by peer
May 15 01:08:59 pond afpd[787267]: read: Connection reset by peer
May 15 01:09:00 pond afpd[787267]: read: Connection reset by peer
May 15 01:09:01 pond afpd[787267]: read: Connection reset by peer
May 15 01:09:02 pond afpd[787267]: read: Connection reset by peer
May 15 01:09:02 pond afpd[787267]: transmit: Request to dbd daemon (volume aduck's home) timed out.
May 15 01:09:02 pond afpd[787267]: afp_openvol(/home/aduck/afpshare): Fatal error: Unable to get stamp value from CNID backend

 

[slipperygrey]

how did you start the AFP server -- via the netatalk controller daemon, or the afpd daemon directly?

the former is the preferred way, because it will bring up the cnid_metad daemon for you (among other things) which is the daemon that orchestrates DBD database access through cnid_dbd daemon processes...

looking at your logs, it could be that no cnid_dbd process gets started, or that the wire protocol communication between afpd and cnid_dbd is blocked by some policy

using the SQLite CNID backend bypasses all that: afpd accesses the SQLite database directly, no need for the cnid_metad/cnid_dbd dance

at some point in the not-too-distant future I plan to make the SQLite backend the default, and flag DBD as deprecated

 

[paws]

Yes, I thought it was something like that. I'm using the netatalk systemd service that comes with the Arch package, but I didn't check if that's straight from upstream or they fiddle with it, so it might be the packaging. At any rate SQLite is a thing I know and trust so if you think it's mature I'd rather use that.