NFS-Dateibesitzer (UID) = 4294967294, kann mit meinem Mount nicht viel anfangen. Wie behebe ich das?

Question

Ich habe hier ein etwas seltsames Setup: Ich habe Android als Client und dessen Kernel unterstützt NFSv4 nicht, außerdem hat meine Datei /etc/exports auf der Serverseite keine Einträge im NFSv4-Stil.

Ich versuche, einige Toolchains zu erstellen (ich habe gcc-4.8-armhf und all das auf meinem Telefon sowie apt-get mit eingerichteten Repositories, sodass ich bei Bedarf Dinge installieren kann) und LFS zu folgen, aber ich kann einige Programme wie Perl nicht erstellen, da ich die Dateieigentümerschaft usw. nicht festlegen kann.

Mein /etc/exports (Server):

/media/usb3/Android     192.168.1.209(rw,sync,subtree_check,no_root_squash)

A ls -lsieht so aus (Client):

drwxr-xr-x  6 4294967294 4294967294      4096 Jun 21 17:23 toolchains
-rw-r--r--  1 4294967294 4294967294         0 Jun 25 18:51 rootu

A sudo chown root:rootsieht so aus (Client) (rootu ist nur eine Testdatei):

sudo chown root:root rootu
chown: changing ownership of `rootu': Invalid argument

Mein Mount-Befehl (Client):

sudo mount -t nfs 192.168.1.210:/media/usb3/Android /home/edge-case/Android-Lab/ -o tcp

Ich habe die Manpages durchgesehen und einige Tutorials und andere Fragen gelesen, aber überall heißt es, man solle einfach „no_root_squash“ festlegen, was ich von Anfang an getan habe, und das funktioniert nicht.

Ich habe im Moment weder LDAP noch Kerberos oder eine andere anspruchsvolle Authentifizierung eingerichtet, das übersteigt im Moment meine Fähigkeiten (und mein Gehalt ist gleich Null). Ich bin zu Hause, habe also vollständigen Root-Zugriff und bin Eigentümer von allem und mache mir keine großen Sorgen um die Sicherheit, außer vielleicht um War-Treiber, aber ich habe ein gutes WLAN-Passwort, also brauche ich wirklich keinen Aluhut ;P

Früher hat das bei mir funktioniert, aber anscheinend wurden einige Änderungen an Debian vorgenommen und es funktioniert nicht mehr so ​​gut. Vermasseln Windows-Agenten den Linux-Quellcode? Nur ein Scherz.

Was ist das wirklich? Wo finde ich eine einfache Möglichkeit, ein Verzeichnis mit Dateien zu mounten, die mir gehören, oder, wenn ich das möchte, Root (über sudo chown), und nicht einem seltsamen „4294967294“-Benutzer, der auf dem Client oder Server nicht existiert?

Answer 1

Ich hasse es, wenn ich das gleich nach dem Stellen der Frage herausfinde.

ich benutzte /system/xbin/busybox mount -t nfs /path/to/share /path/to/mountpoint -o tcp,nolock

Es funktioniert, jetzt gehören meine Dateien meinem Benutzer „10001:10001“ auf dem Client, aber es ist eine chaotische Lösung, denn wenn ich Cyanogenmods busybox mountohne die nolockOption verwende, wird die Berechtigung verweigert, aber wenn ich Debians Mount mit der nolockOption verwende, haben sie immer noch den seltsamen UID:GID-Besitz.

Derzeit funktioniert es also nur mit Cyanogenmods busybox mount. nolockDie Verwendung nolockmit Debian mountbehebt das ID-Problem nicht und ohne nolockCyanogenmods wird mir die Berechtigung verweigert.

Ich denke, die richtige Lösung wäre, die Quelle für jeden durchzugehen und Debians mountBefehl mit einem Patch neu zu erstellen, damit er wie der von Cyan ist, und herauszufinden, warum ich das brauche nolock. Ich glaube nicht, dass ich das brauchen sollte. Vielleicht ist es ein Linker-/Bibliotheksproblem? Keine Ahnung, im Moment ist mir das nicht klar.