Thanks for looking into this, Paul. But there's a big misunderstanding. This is not on Android. It's on Linux with glibc (Ubuntu 22.04, to be precise), as can be seen from the log file: openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 and from the fact that I could write to /tmp.
The fchownat() failure comes from the combination of a 'cifs' mount of the Linux kernel (mount options: rw,relatime,vers=1.0,cache=strict,username=bruno,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.**.**,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1 ) and the CIFS/SMB server on my NAS (an old Linux/mips machine). > Although the attached hacky coreutils patch (which I haven't installed) > might solve the immediate problem Unfortunately, this patch would also silence warnings that are justified (e.g. when a normal user moves a directory owned by 'root', whose parent directory has mode drwxrwxrwx). I think the diagnostic should only be supporessed when, despite the failed fchownat() call, the destination has the same uid and gid as the 3rd and 4th argument of the fchownat() invocation. > it sounds like this is something that Gnulib's fchownat Whether this is better done in Gnulib or in coreutils/src/copy.c, I can't judge. Bruno
