> -----Original Message----- > From: Amir Goldstein <amir73il@xxxxxxxxx> > Sent: Wednesday, September 21, 2022 10:42 AM > To: Jie, Keyon <keyon.jie@xxxxxxxxx> > Cc: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx>; Miklos Szeredi > <miklos@xxxxxxxxxx>; overlayfs <linux-unionfs@xxxxxxxxxxxxxxx> > Subject: Re: Does overlay driver work if built in to the kernel? > > On Wed, Sep 21, 2022 at 5:48 PM Jie, Keyon <keyon.jie@xxxxxxxxx> wrote: > > > > > > > -----Original Message----- > > > From: Amir Goldstein <amir73il@xxxxxxxxx> > > > Sent: Tuesday, September 20, 2022 11:50 PM > > > To: Keyon Jie <yang.jie@xxxxxxxxxxxxxxx> > > > Cc: Miklos Szeredi <miklos@xxxxxxxxxx>; overlayfs <linux- > > > unionfs@xxxxxxxxxxxxxxx>; Jie, Keyon <keyon.jie@xxxxxxxxx> > > > Subject: Re: Does overlay driver work if built in to the kernel? > > > > > > On Wed, Sep 21, 2022 at 3:32 AM Keyon Jie <yang.jie@xxxxxxxxxxxxxxx> > > > wrote: > > > > > > > > Hi all, > > > > > > > > I am new to the overlayfs, I am hitting issues to make kernel modules > > > > work in a container environment where the Kubernetes feature really > > > need > > > > the overlayfs support. > > > > > > > > I figured out to make overlay driver built-in to the VM kernel (and > then > > > > shared to the container), but looks like the Kubernetes always fail > when > > > > trying to create overlayfs mounts, with errors like 'permission denied'. > > > > > > > > > > Usually, you want to look at the kernel log to see the reason for failure. > > > That is likely because the container is "unprivileged" > > > meaning not using the same uid 0 as the host. > > > > > > Don't know which kernel you are running, but overlayfs can be mounted > > > inside unprivileged container since kernel v5.11: > > > > > > https://lore.kernel.org/linux- > > > fsdevel/20201217142025.GB1236412@xxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > Thank you Amir. > > I am using v5.10 kernel, so looks I can try to backport some of the patches > and try it again. > > I assume take the 10-commits series from Miklos should be enough? > > vfs: move cap_convert_nscap() call into vfs_setxattr() > > vfs: verify source area in vfs_dedupe_file_range_one() > > ovl: check privs before decoding file handle > > ovl: make ioctl() safe > > ovl: simplify file splice > > ovl: user xattr > > ovl: do not fail when setting origin xattr > > ovl: do not fail because of O_NOATIME > > ovl: do not get metacopy for userxattr > > ovl: unprivieged mounts > > https://lore.kernel.org/linux-fsdevel/1725e01a-4d4d-aecb-bad6- > 54aa220b4cd2@xxxxxxxxxxxxxxxxxxx/T/ > > > > Not sure you can try. > There may be other bug fixes that need backporting. > It is not recommended to backport such a feature by yourself. > You would be much better off taking or build a newer LTS kernel (e.g. 5.15.y) Thank you so much Amir. Just tried and 5.15 works well for me! Thanks, ~Keyon > > Thanks, > Amir.
