search

rdmark / netatalk-2.x

Netatalk is an Open-Source AFP file server for Linux, NetBSD, and Solaris, capable of serving AppleShare over AppleTalk and TCP/IP with multiple Macintosh or Apple II clients.
Other
51 stars 2 forks source link

Read-only filesystems and `-dbpath` #15

Open saybur opened 2 years ago

saybur commented 2 years ago

It looks like netatalk does not like it when the base directory of a share is mounted read-only at the filesystem level. As I read the docs, it seems like this should be OK as long as -dbpath is specified and placed somewhere that is read/write. However, if you try to specify a RO location with a RW dbpath, shares do not mount correctly on clients.

The example below is on Debian buster, where /mnt/shared is read-only in fstab, and is set up in AppleVolumes.default as follows:

:DEFAULT: options:upriv,usedots
/mnt/shared "Shared" options:ro dbpath:/var/cache/shared_db

After mounting this share on the client and double-clicking it, Mac OS seems to freeze up. On the server, this appears in syslog:

Aug 17 21:09:11 vesta cnid_metad[30997]: allocvolinfo("/mnt/shared"): No such file or directory
Aug 17 21:09:11 vesta afpd[31196]: read: Connection reset by peer

This is repeated once a second or so for ~15 seconds, then the following is reported. The client unfreezes and shows an empty share.

Aug 17 21:09:26 vesta afpd[31196]: transmit: Request to dbd daemon (db_dir /mnt/shared) timed out.
Aug 17 21:09:26 vesta afpd[31196]: Reopen volume /mnt/shared using in memory temporary CNID DB.
Aug 17 21:09:26 vesta afpd[31196]: Cannot find module named [tdb] in registered module list!

This is similar to the report from https://sourceforge.net/p/netatalk/mailman/message/28737511/ except for the tdb module missing message. Per NEWS it looks like the tdb backend is gone, so that might have something to do with this as well.

Anyway, this is easy enough to work around by ensuring that the base of a share is mounted R/W. Maybe this is documented somewhere and I just missed it. Otherwise, it might be a good idea to fail-fast and warn that sharing RO filesystems is not supported.

rdmark commented 2 years ago

Thanks for reporting! I've personally not ever attempted to mount read-only file systems, so I wasn't aware of this corner case. From that mailing list thread, it seems like a legacy bug/limitation. I agree that afpd should either fail early and with an accurate error message, or CNID should be modified to handle read-only file systems. Netatalk certainly supports read-only AFP shares, so it might be a handy shortcut for setting up a "secure" read-only file server. Thoughts?

saybur commented 2 years ago

The secure read-only share is my use case - I prefer to mount my main fileserver share read-only inside a VM dedicated to just my retro network, to keep any odd malfunctions or ancient malware from causing grief :)

As a user I'd be fine with either of the approaches you listed. That said, I don't know how common what I'm doing is, and since the workaround I used is pretty trivial a faster/more accurate error message might be the simpler way to go.