PoC: Neu

2018-04-17T20:48:50Z

Neu

Neue Seite

Bei einem '''Re-Export eines NFS-Exports via Netatalk''' können beim ersten Doppelklick folgende Meldungen im Syslog auftauchen, während auf der Mac-Seite für ca. 20 Sekunden scheinbar gar nichts geht:

Apr 17 20:03:15 afpbridge cnid_metad[16791]: allocvolinfo("/home/blahfasel"): Permission denied
Apr 17 20:03:15 afpbridge afpd[16804]: read: Connection reset by peer
[…]
Apr 17 20:03:36 afpbridge afpd[16804]: transmit: Request to dbd daemon (db_dir /home/blahfasel) timed out.
Apr 17 20:03:36 afpbridge afpd[16804]: Reopen volume /home/blahfasel using in memory temporary CNID DB.
Apr 17 20:03:36 afpbridge afpd[16804]: dsi_stream_write: Socket operation on non-socket

Die Ursache liegt darin begründet, dass bei Netatalk per Default ein eigener Task<ref>Der ''cnid_metad''.</ref> die Kommunikation zwischen mehreren AFP-Clients (auf einem Volume) und der dort gespeicherten BDB-Datei mit den Zuordnungen von Dateinamen zu Datei-IDs regelt.<ref>Es gab hier wohl oftmals kaputte BDB-Dateien; ein Zugriff auf das Volume war dann überhaupt nicht mehr möglich.</ref> Dieser läuft als ''root'' und versucht demnach auch als ''root'' auf diese Datenbankdatei zuzugreifen.

== Lösung 1 ==
Der NFS-Server darf den ''root''-User nicht auf ''nobody'' umlenken. In der ''/etc/exports'' muss hierzu der Parameter ''no_root_squash'' für den jeweiligen Export ergänzt werden.

'''Achtung!''' Das ermöglicht es bei zu großzügiger Auslegung, welche Adressen sich verbinden dürfen zu einem netten Sicherheitsloch: Jegliche Zugriffsbeschränkungen sind außer Kraft gesetzt. Was ''root'' auf der ungeplant zugreifenden Maschine machen darf, darf er auch via NFS auf dem Export tun.

== Lösung 2 ==
Wenn man auf den ''cnid_metad'' verzichtet und die jeweiligen AFP-Server-Tasks selbst die Datenbankdatei öffnen, so geschieht das als der jeweilig per AFP angemeldete Benutzer und nicht mehr als ''root''. Somit kann die BDB-Datei bearbeitet werden, allerdings mit dem angesprochenen Risiko von defekten DB-Dateien bei Abstürzen u. Ä.

Außerdem ist dieses ID-Schema zumindest in der bei Debian 9 mitgelieferten Netatalk-Version nicht (mehr) verfügbar. Hier muss Netatalk mit dem entsprechenden Feature neu kompiliert werden.<ref>Ungetestet! Rückmeldungen erbeten.</ref>

== Weblinks ==
* [http://netatalk.sourceforge.net/2.2/htmldocs/configuration.html#CNID-backends Netatalk-Dokumentation: CNID backends], Chapter 3. Setting up Netatalk.

== Fußnoten ==
<references />

[[Kategorie:Linux]]
[[Kategorie:Mac OS]]

NFS-Exports per Netatalk reexportieren - Versionsgeschichte

PoC: Neu