($INBOX_DIR/description missing)
 help / color / Atom feed
* odd error: why: mount: /home2: mount(2) system call failed: Stale file handle
@ 2021-04-08 18:58 L. A. Walsh
  2021-04-09  5:44 ` Amir Goldstein
  0 siblings, 1 reply; 4+ messages in thread
From: L. A. Walsh @ 2021-04-08 18:58 UTC (permalink / raw)
  To: overlayfs

Started to try overlay fs w/one fs, but decided on another, so
umounted the first -- hadn't done any changes.

Then tried a different lower dir (/home) and tried to mount into new
dir /home2.  Got:
mount: /home2: mount(2) system call failed: Stale file handle

any idea why?  I cleared out contents of workdir (two empty dirs)
but still didn't work again.

running a Vanilla-ish self-made kernel version 5.9.2...
don't know what other info I should provide...oh well...


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: odd error: why: mount: /home2: mount(2) system call failed: Stale file handle
  2021-04-08 18:58 odd error: why: mount: /home2: mount(2) system call failed: Stale file handle L. A. Walsh
@ 2021-04-09  5:44 ` Amir Goldstein
  2021-04-10 19:34   ` L A Walsh
  0 siblings, 1 reply; 4+ messages in thread
From: Amir Goldstein @ 2021-04-09  5:44 UTC (permalink / raw)
  To: L. A. Walsh; +Cc: overlayfs

On Thu, Apr 8, 2021 at 10:18 PM L. A. Walsh <lkml@tlinx.org> wrote:
>
> Started to try overlay fs w/one fs, but decided on another, so
> umounted the first -- hadn't done any changes.
>
> Then tried a different lower dir (/home) and tried to mount into new
> dir /home2.  Got:
> mount: /home2: mount(2) system call failed: Stale file handle
>
> any idea why?  I cleared out contents of workdir (two empty dirs)
> but still didn't work again.
>
> running a Vanilla-ish self-made kernel version 5.9.2...
> don't know what other info I should provide...oh well...
>

You should normally at least look at kmsg, where you are likely to
find "overlayfs: failed to verify upper root origin".

It is generally not allowed to reuse the upper layer and replace the
lower layers after overlayfs has been mounted once.

If you say you did not change anything, it is not clear what is the
benefit of reusing  the empty upper layer.

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: odd error: why: mount: /home2: mount(2) system call failed: Stale file handle
  2021-04-09  5:44 ` Amir Goldstein
@ 2021-04-10 19:34   ` L A Walsh
  2021-04-11  4:45     ` Amir Goldstein
  0 siblings, 1 reply; 4+ messages in thread
From: L A Walsh @ 2021-04-10 19:34 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: overlayfs

On 2021/04/08 22:44, Amir Goldstein wrote:
> It is generally not allowed to reuse the upper layer and replace the
> lower layers after overlayfs has been mounted once.
>
> If you say you did not change anything, it is not clear what is the
> benefit of reusing  the empty upper layer.
>   
---
    I can understand that, the upper layer is an empty fs+work dir
with no changes.  It was attached to the wrong lower layer,
unattached/unmounted.

    I then made sure both upper+work were both empty and tried again
elsewhere.  I want to avoid unnecessary steps, so destroying and recreating
an empty partition didn't seem logical.  How do you disassociate a
previous connected state?  What needs to be initialized on the
unmounted upper and working dir (on the same fs), to reuse the same
file system?




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: odd error: why: mount: /home2: mount(2) system call failed: Stale file handle
  2021-04-10 19:34   ` L A Walsh
@ 2021-04-11  4:45     ` Amir Goldstein
  0 siblings, 0 replies; 4+ messages in thread
From: Amir Goldstein @ 2021-04-11  4:45 UTC (permalink / raw)
  To: L A Walsh; +Cc: overlayfs

On Sat, Apr 10, 2021 at 10:34 PM L A Walsh <lkml@tlinx.org> wrote:
>
> On 2021/04/08 22:44, Amir Goldstein wrote:
> > It is generally not allowed to reuse the upper layer and replace the
> > lower layers after overlayfs has been mounted once.
> >
> > If you say you did not change anything, it is not clear what is the
> > benefit of reusing  the empty upper layer.
> >
> ---
>     I can understand that, the upper layer is an empty fs+work dir

You must mean empty fs+upper dir+work dir. No?

> with no changes.  It was attached to the wrong lower layer,
> unattached/unmounted.
>
>     I then made sure both upper+work were both empty and tried again
> elsewhere.  I want to avoid unnecessary steps, so destroying and recreating
> an empty partition didn't seem logical.

I am probably missing something. How is this complicated?
rmdir upperdir workdir; mkdir upperdir workdir

> How do you disassociate a
> previous connected state?  What needs to be initialized on the
> unmounted upper and working dir (on the same fs), to reuse the same
> file system?
>

You need to remove the trusted.overlay.* xattrs, but I still don't
understand what's the complication with re-creating two empty dirs.

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-08 18:58 odd error: why: mount: /home2: mount(2) system call failed: Stale file handle L. A. Walsh
2021-04-09  5:44 ` Amir Goldstein
2021-04-10 19:34   ` L A Walsh
2021-04-11  4:45     ` Amir Goldstein

($INBOX_DIR/description missing)

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-unionfs/0 linux-unionfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-unionfs linux-unionfs/ https://lore.kernel.org/linux-unionfs \
		linux-unionfs@vger.kernel.org
	public-inbox-index linux-unionfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-unionfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git