Vespa content pod created snapshot folder owned by nobody user in a high RAM situation about vespa HOT 3 OPEN

As far as I know, the search core does not set or modify the ownership of its data directories or files. However—is this by any chance running on an XFS filesystem? We have observed this exact scenario very spuriously on XFS during periods with lots of IO and file syncing, but only when the kernel file system buffer cache and/or directory entries cache is being concurrently flushed/evicted.

The observed result was a directory with partially bogus inode metadata, in particular an owner that does not make sense (we've seen uid/gid of both 65534 and 0, neither of which are correct). Also note the Links: 1 field—I would expect a correct directory inode to have at least 2 links since a directory should normally include a hard-link to itself (note; does not apply to all file systems—Btrfs for instance seems to just have 1).

The scenario you describe is one where the kernel is under a very high memory pressure, and where it's likely to try to evict file system caches to get more available memory for applications. If so, the preconditions are similar to what we have observed.

Note: this is inherently just a theory, and we have not had the time to do a deep dive into figuring this out (particularly since doing so would involve reading lots of kernel code). I've tried reproducing this issue by writing a program that stresses the kernel file system cache management through lots of concurrent nested directory creation, fsyncing and forced cache eviction, but never managed to trigger it.

from vespa.

It is XFS indeed

from vespa.