NFS-Exports per Netatalk reexportieren

Aus Knowledgebase
Version vom 17. April 2018, 21:48 Uhr von PoC (Diskussion | Beiträge) (Neu)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

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[1] die Kommunikation zwischen mehreren AFP-Clients (auf einem Volume) und der dort gespeicherten BDB-Datei mit den Zuordnungen von Dateinamen zu Datei-IDs regelt.[2] 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.[3]

Weblinks

Fußnoten

  1. Der cnid_metad.
  2. Es gab hier wohl oftmals kaputte BDB-Dateien; ein Zugriff auf das Volume war dann überhaupt nicht mehr möglich.
  3. Ungetestet! Rückmeldungen erbeten.