https://kb.pocnet.net/index.php?title=NFS-Exports_per_Netatalk_reexportieren&feed=atom&action=historyNFS-Exports per Netatalk reexportieren - Versionsgeschichte2024-03-29T13:08:52ZVersionsgeschichte dieser Seite in KnowledgebaseMediaWiki 1.35.11https://kb.pocnet.net/index.php?title=NFS-Exports_per_Netatalk_reexportieren&diff=2131&oldid=prevPoC: Neu2018-04-17T20:48:50Z<p>Neu</p>
<p><b>Neue Seite</b></p><div>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:<br />
<br />
Apr 17 20:03:15 afpbridge cnid_metad[16791]: allocvolinfo("/home/blahfasel"): Permission denied<br />
Apr 17 20:03:15 afpbridge afpd[16804]: read: Connection reset by peer<br />
[…]<br />
Apr 17 20:03:36 afpbridge afpd[16804]: transmit: Request to dbd daemon (db_dir /home/blahfasel) timed out.<br />
Apr 17 20:03:36 afpbridge afpd[16804]: Reopen volume /home/blahfasel using in memory temporary CNID DB.<br />
Apr 17 20:03:36 afpbridge afpd[16804]: dsi_stream_write: Socket operation on non-socket<br />
<br />
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.<br />
<br />
== Lösung 1 ==<br />
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.<br />
<br />
'''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.<br />
<br />
== Lösung 2 ==<br />
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.&thinsp;Ä.<br />
<br />
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><br />
<br />
== Weblinks ==<br />
* [http://netatalk.sourceforge.net/2.2/htmldocs/configuration.html#CNID-backends Netatalk-Dokumentation: CNID backends], Chapter 3. Setting up Netatalk.<br />
<br />
== Fußnoten ==<br />
<references /><br />
<br />
[[Kategorie:Linux]]<br />
[[Kategorie:Mac OS]]</div>PoC