Linux Container Development
 help / color / mirror / Atom feed
From: Philipp Wendler <ml-PRuqubkS1MrCxoAYUeDZubNAH6kLmebB@public.gmane.org>
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: Using overlayfs in (unprivileged) namespace
Date: Mon, 15 Feb 2016 15:46:44 +0100	[thread overview]
Message-ID: <56C1E4D4.5070400@philippwendler.de> (raw)
In-Reply-To: <56C1C674.3030705-6AxghH7DbtA@public.gmane.org>

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

  parent reply	other threads:[~2016-02-15 14:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15 11:04 Using overlayfs in (unprivileged) namespace Philipp Wendler
     [not found] ` <56C1B0C6.6080806-PRuqubkS1MrCxoAYUeDZubNAH6kLmebB@public.gmane.org>
2016-02-15 11:47   ` Nikolay Borisov
     [not found]     ` <56C1BAE2.30209-6AxghH7DbtA@public.gmane.org>
2016-02-15 12:30       ` Philipp Wendler
     [not found]         ` <56C1C4D7.8030406-PRuqubkS1MrCxoAYUeDZubNAH6kLmebB@public.gmane.org>
2016-02-15 12:37           ` Nikolay Borisov
     [not found]             ` <56C1C674.3030705-6AxghH7DbtA@public.gmane.org>
2016-02-15 14:46               ` Philipp Wendler [this message]
2016-02-15 18:18   ` Serge Hallyn
2016-02-15 18:47     ` Philipp Wendler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C1E4D4.5070400@philippwendler.de \
    --to=ml-pruqubks1mrcxoayuedzubnah6klmebb@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox