SSHFS-Rechteverwaltung in der virtualisierten Build-Umgebung von Debian 9

Ich arbeite mit einem Setup, bei dem die Build-Maschine virtualisiert ist und auf den Speicher für den Build-Prozess über eine Netzwerkfreigabe zugegriffen wird:

VM-Hostbetriebssystem: Debian 8
VM-Manager: VirtualBox
VM- Clientbetriebssystem : Debian 9
Netzwerkfreigabe: SSHFS
Projekt, das erstellt wird: OpenWRT

SSHFS hat sich bei der Rechteverwaltung im Bauprozess im Allgemeinen gut verhalten. Ein Problem hat mich jedoch überrascht:

. /media/openwrt_build/openwrt/include/shell.sh; bzcat /media/openwrt_build/openwrt/dl/u-boot-2014.10.tar.bz2 | tar -C /media/openwrt_build/openwrt/build_dir/host/u-boot-2014.10/.. -xf -  tar: u-boot-2014.10/tools/buildman/buildman: Cannot utime: No such file or directory tar: u-boot-2014.10/tools/patman/patman: Cannot utime: No such file or directory tar: Exiting with failure status due to previous errors Makefile:46: recipe for target '/media/openwrt_build/openwrt/build_dir/host/u-boot-2014.10/.prepared86e9d8870a885c630b99e1ea2fa45daf' failed make[3]: *** [/media/openwrt_build/openwrt/build_dir/host/u-boot-2014.10/.prepared86e9d8870a885c630b99e1ea2fa45daf] Error 2 make[3]: Leaving directory '/media/openwrt_build/openwrt/tools/mkimage' tools/Makefile:147: recipe for target 'tools/mkimage/compile' failed make[2]: *** [tools/mkimage/compile] Error 2 

Google schlägt vor, dass dies Cannot utime: No such file or directoryeine häufige Antwort auf fehlgeschlagene Versuche ist, Benutzer / Gruppen / Rechte der aus einem Tarball extrahierten Dateien zu erhalten. In diesem Fall vermute ich, dass der Versuch, die Rechte aus dem Tarball zu erhalten, mit der Einrichtung des SSHFS-Mount für die Verwaltung der Rechte kollidiert.

Es gibt eine Reihe von Optionen, die beim Mounten eines freigegebenen SSHFS-Ordners festgelegt werden können, aber ich konnte nicht herausfinden, was dieses Problem lösen könnte. Derzeit mounte ich den Ordner wie folgt:

sshfs nonrootuser1@ip.ad.dr.ess:/folder/to/mount /local/mount/point 

Ein weiterer wahrscheinlicher Fehlerpunkt könnte die Rechteverwaltung des Host-Quellordners und des Client-Mount-Ordners sein. Die Erfahrungen aus anderen Fällen zeigen jedoch, dass ich wahrscheinlich nicht so weit gekommen wäre, wenn dies das Problem wäre.

ls -l enthält die folgenden Informationen zu Host- und Clientordnern:

drwxrwxrwx 8 nonrootuser1 nonrootuser1 4096 Jun 25 19:39 /folder/to/mount  drwxr-xr-x 2 nonrootuser2 nonrootuser2 4096 Jun 23 12:36 /local/mount/point 

Lösungen und Vorschläge, die zur Lösung des utimeProblems beitragen können, sind sehr willkommen.