Re: nfs_export Stale file handle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 20, 2021 at 12:42 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Tue, Oct 19, 2021 at 10:49 PM Carl Karsten <carl@xxxxxxxxxxxxxxxx> wrote:
> >
> > I am sure this worked once, then I rebooted and now something ....
>
> Are you saying it is a regression? From which kernel?

Not a regression - just something that I am sure was OK on my box,
then 20 min later the 'same thing' is causing problems.  We all know
it isn't the same, but this is what has me scratching my head.

>
> >
> > root@negk:/srv/nfs/rpi/root# mount -v -t overlay -o nfs_export=on
> > overlay -olowerdir=img,upperdir=upper,workdir=work merged
> > mount: /srv/nfs/rpi/root/merged: mount(2) system call failed: Stale file handle.
> >
>
> What are lower and upper?

img was
/dev/mapper/loop2p2 on /srv/nfs/rpi/buster/root/img type ext4 (rw,relatime)

> cat /proc/self/mountinfo please

sorry, I've reinstalled the os and I'm not having this problem any more.

> If you happen to be using squashfs for lower fs, there were a bunch
> of changes and fixes in recent kernels.

no squashfs

>
> > # this works:
> > root@negk:/srv/nfs/rpi/root# mount -v -t overlay -o nfs_export=off
> > overlay -olowerdir=img,upperdir=upper,workdir=work merged
> > mount: overlay mounted on /srv/nfs/rpi/root/merged.
> > root@negk:/srv/nfs/rpi/root# umount merged
> >
> > # syslog:
> >
> > [   80.317697] overlayfs: failed to verify origin (root/img,
> > ino=2374476, err=-116)
> > [   80.317703] overlayfs: failed to verify upper root origin
> >
> > # no help:
> > systemctl disable nfs-server.service
> > reboot
> > root@negk:/srv/nfs/rpi/root# systemctl status nfs-server.service
> > ● nfs-server.service - NFS server and services
> >      Loaded: loaded (/lib/systemd/system/nfs-server.service; disabled;
> > vendor preset: enabled)
> >      Active: inactive (dead)
> >
>
> The error has nothing to do with NFS.
> The staleness is that of the root/img directory.
> Overlayfs believes that someone has replaced the original
> root/img directory with another directory on the same name
> but a different file handle.
>

the only difference between error and no error was

nfs_export=off / on

Which is mostly why I posted - this little detail seemed odd.

> Did you re-create the lower image filesystem/subtree?

maybe.  I'm futzing around with this pi image file trying to figure
out how to manage various flavors of modifications. .
I was hoping the lowest level would be the fs in the .img file, but
there isn't a nice way to deal with the loop devices, so I'll copy the
files onto the base ext5 fs and get on with things.

At the moment my little sysadmin project has lots of moving parts that
are not at all reliable, it's hard to tell what is and isn't working.
robust is the goal, I'm getting there.


> See Documentation clarification commit
> 13c6ad0f45fd ("ovl: document lower modification caveats")
>
> Thanks,
> Amir.



-- 
Carl K




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux