Using overlayfs in (unprivileged) namespace

Philipp Wendler ml at philippwendler.de
Mon Feb 15 14:46:44 UTC 2016


Hello,

Am 15.02.2016 um 13:37 schrieb Nikolay Borisov:
> On 02/15/2016 02:30 PM, Philipp Wendler wrote:
>> I have looked into ftrace now, but I didn't find a way how to see which
>> function is responsible for letting the rm fail.
>> The kernel documentation on ftrace is quite overwhelming, so maybe I
>> have missed something.
>> Do you have by chance a more specific pointer to what would help me?
> 
> If I were you I would run something along the lines of (inside the
> container):
> 
> trace-cmd record -p function_graph -F rm some-file
> 
> And then you would do :
> 
> trace-cmd report
> 
> and see the resulting call trace and quite possibly it might be failing
> in an ovl_* prefixed function.

Thanks, this was very helpful, and I know now that I was on a wrong path.

>From the trace, I noticed that my Ubuntu kernel actually has an
additional legacy mode of overlayfs which I was using (unintentionally),
and which instead of creating a device node, creates a symlink and tries
to set the "trusted.overlay.whiteout" xattr on it, which fails.
So the failure has nothing to do with devices, sorry for the confusion.

The legacy mode got triggered by the "-t overlayfs" parameter to mount.
If I specify "-t overlay" instead, the normal mode gets used (which
seems to match the one in the vanilla kernel), and with this everything
appears to work nicely, regardless of whether the user namespace was
created by a privileged or an unprivileged user.

So sorry for the confusion and thank you very much for helping me
debugging this!

Greetings, Philipp


More information about the Containers mailing list