Overlayfs over archivemount
up vote
1
down vote
favorite
I am trying to apply an overlay using overlayfs
over a filesystem mounted with archivemount
:
mkdir -p {upper,work,mount}
tar zcf somefile upper/ work/ mount/
mkdir tmp
archivemount -o allow_root -o fsname=ext4 somefile tmp
sudo mount -t overlay -o lowerdir=/,upperdir=tmp/upper,workdir=tmp/work overlayfs tmp/mount
However, mount fails with:
mount: /tmp/test8/tmp/mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error.
Looking at dmesg, I see:
overlayfs: filesystem on 'tmp/upper' not supported as upperdir
Why would archivemount not supported? Is there a way around that problem?
linux fuse overlayfs
add a comment |
up vote
1
down vote
favorite
I am trying to apply an overlay using overlayfs
over a filesystem mounted with archivemount
:
mkdir -p {upper,work,mount}
tar zcf somefile upper/ work/ mount/
mkdir tmp
archivemount -o allow_root -o fsname=ext4 somefile tmp
sudo mount -t overlay -o lowerdir=/,upperdir=tmp/upper,workdir=tmp/work overlayfs tmp/mount
However, mount fails with:
mount: /tmp/test8/tmp/mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error.
Looking at dmesg, I see:
overlayfs: filesystem on 'tmp/upper' not supported as upperdir
Why would archivemount not supported? Is there a way around that problem?
linux fuse overlayfs
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am trying to apply an overlay using overlayfs
over a filesystem mounted with archivemount
:
mkdir -p {upper,work,mount}
tar zcf somefile upper/ work/ mount/
mkdir tmp
archivemount -o allow_root -o fsname=ext4 somefile tmp
sudo mount -t overlay -o lowerdir=/,upperdir=tmp/upper,workdir=tmp/work overlayfs tmp/mount
However, mount fails with:
mount: /tmp/test8/tmp/mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error.
Looking at dmesg, I see:
overlayfs: filesystem on 'tmp/upper' not supported as upperdir
Why would archivemount not supported? Is there a way around that problem?
linux fuse overlayfs
I am trying to apply an overlay using overlayfs
over a filesystem mounted with archivemount
:
mkdir -p {upper,work,mount}
tar zcf somefile upper/ work/ mount/
mkdir tmp
archivemount -o allow_root -o fsname=ext4 somefile tmp
sudo mount -t overlay -o lowerdir=/,upperdir=tmp/upper,workdir=tmp/work overlayfs tmp/mount
However, mount fails with:
mount: /tmp/test8/tmp/mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error.
Looking at dmesg, I see:
overlayfs: filesystem on 'tmp/upper' not supported as upperdir
Why would archivemount not supported? Is there a way around that problem?
linux fuse overlayfs
linux fuse overlayfs
edited 2 days ago
Jeff Schaller
37.5k1052121
37.5k1052121
asked 2 days ago
Luke Skywalker
1135
1135
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
The documentation for the overlayfs kernel module states:
The upper filesystem will normally be writable and if it is it must support the creation of
trusted.*
extended attributes, and
must provide validd_type
inreaddir
responses, so NFS is not suitable.
So archivemount
probably doesn't implement either one of these features, which makes it unsuitable for use as a upper layer in a writable overlayfs.
Note that the documentation continues with:
A read-only overlay of two read-only filesystems may use any filesystem type.
So if a read-only overlayfs is enough for your needs, setting it up on top of archivemount
should work even for the lower layer, just having to mount everything read-only for that case.
Note that there aren't limitations in the FUSE protocol itself that make any FUSE mounts unsuitable for use as a writable upper layer in overlayfs.
Specifically, FUSE exposes functions to query and set extended attributes and it also exposes the d_type
field for implementations to fill.
But specific FUSE applications need to implement those features for them to be available.
Regarding extended attributes, a separate technical limitation for archivemount
is that not all archive formats support storing extended attributes, so it's possible even if archivemount
would implement support for extended attributes, that it would not be available on all supported archive formats.
(See documentation for --xattrs
option of GNU tar for some more details.)
I missed that bit of the tar documentation. I tried it and it didn't help. Note thatarchivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.
– Luke Skywalker
2 days ago
1
@LukeSkywalker Looking at the code, it doesn't seem likearchivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references tod_type
either, so it seems it doesn't implement that either...
– Filipe Brandenburger
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The documentation for the overlayfs kernel module states:
The upper filesystem will normally be writable and if it is it must support the creation of
trusted.*
extended attributes, and
must provide validd_type
inreaddir
responses, so NFS is not suitable.
So archivemount
probably doesn't implement either one of these features, which makes it unsuitable for use as a upper layer in a writable overlayfs.
Note that the documentation continues with:
A read-only overlay of two read-only filesystems may use any filesystem type.
So if a read-only overlayfs is enough for your needs, setting it up on top of archivemount
should work even for the lower layer, just having to mount everything read-only for that case.
Note that there aren't limitations in the FUSE protocol itself that make any FUSE mounts unsuitable for use as a writable upper layer in overlayfs.
Specifically, FUSE exposes functions to query and set extended attributes and it also exposes the d_type
field for implementations to fill.
But specific FUSE applications need to implement those features for them to be available.
Regarding extended attributes, a separate technical limitation for archivemount
is that not all archive formats support storing extended attributes, so it's possible even if archivemount
would implement support for extended attributes, that it would not be available on all supported archive formats.
(See documentation for --xattrs
option of GNU tar for some more details.)
I missed that bit of the tar documentation. I tried it and it didn't help. Note thatarchivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.
– Luke Skywalker
2 days ago
1
@LukeSkywalker Looking at the code, it doesn't seem likearchivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references tod_type
either, so it seems it doesn't implement that either...
– Filipe Brandenburger
2 days ago
add a comment |
up vote
1
down vote
The documentation for the overlayfs kernel module states:
The upper filesystem will normally be writable and if it is it must support the creation of
trusted.*
extended attributes, and
must provide validd_type
inreaddir
responses, so NFS is not suitable.
So archivemount
probably doesn't implement either one of these features, which makes it unsuitable for use as a upper layer in a writable overlayfs.
Note that the documentation continues with:
A read-only overlay of two read-only filesystems may use any filesystem type.
So if a read-only overlayfs is enough for your needs, setting it up on top of archivemount
should work even for the lower layer, just having to mount everything read-only for that case.
Note that there aren't limitations in the FUSE protocol itself that make any FUSE mounts unsuitable for use as a writable upper layer in overlayfs.
Specifically, FUSE exposes functions to query and set extended attributes and it also exposes the d_type
field for implementations to fill.
But specific FUSE applications need to implement those features for them to be available.
Regarding extended attributes, a separate technical limitation for archivemount
is that not all archive formats support storing extended attributes, so it's possible even if archivemount
would implement support for extended attributes, that it would not be available on all supported archive formats.
(See documentation for --xattrs
option of GNU tar for some more details.)
I missed that bit of the tar documentation. I tried it and it didn't help. Note thatarchivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.
– Luke Skywalker
2 days ago
1
@LukeSkywalker Looking at the code, it doesn't seem likearchivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references tod_type
either, so it seems it doesn't implement that either...
– Filipe Brandenburger
2 days ago
add a comment |
up vote
1
down vote
up vote
1
down vote
The documentation for the overlayfs kernel module states:
The upper filesystem will normally be writable and if it is it must support the creation of
trusted.*
extended attributes, and
must provide validd_type
inreaddir
responses, so NFS is not suitable.
So archivemount
probably doesn't implement either one of these features, which makes it unsuitable for use as a upper layer in a writable overlayfs.
Note that the documentation continues with:
A read-only overlay of two read-only filesystems may use any filesystem type.
So if a read-only overlayfs is enough for your needs, setting it up on top of archivemount
should work even for the lower layer, just having to mount everything read-only for that case.
Note that there aren't limitations in the FUSE protocol itself that make any FUSE mounts unsuitable for use as a writable upper layer in overlayfs.
Specifically, FUSE exposes functions to query and set extended attributes and it also exposes the d_type
field for implementations to fill.
But specific FUSE applications need to implement those features for them to be available.
Regarding extended attributes, a separate technical limitation for archivemount
is that not all archive formats support storing extended attributes, so it's possible even if archivemount
would implement support for extended attributes, that it would not be available on all supported archive formats.
(See documentation for --xattrs
option of GNU tar for some more details.)
The documentation for the overlayfs kernel module states:
The upper filesystem will normally be writable and if it is it must support the creation of
trusted.*
extended attributes, and
must provide validd_type
inreaddir
responses, so NFS is not suitable.
So archivemount
probably doesn't implement either one of these features, which makes it unsuitable for use as a upper layer in a writable overlayfs.
Note that the documentation continues with:
A read-only overlay of two read-only filesystems may use any filesystem type.
So if a read-only overlayfs is enough for your needs, setting it up on top of archivemount
should work even for the lower layer, just having to mount everything read-only for that case.
Note that there aren't limitations in the FUSE protocol itself that make any FUSE mounts unsuitable for use as a writable upper layer in overlayfs.
Specifically, FUSE exposes functions to query and set extended attributes and it also exposes the d_type
field for implementations to fill.
But specific FUSE applications need to implement those features for them to be available.
Regarding extended attributes, a separate technical limitation for archivemount
is that not all archive formats support storing extended attributes, so it's possible even if archivemount
would implement support for extended attributes, that it would not be available on all supported archive formats.
(See documentation for --xattrs
option of GNU tar for some more details.)
edited 2 days ago
answered 2 days ago
Filipe Brandenburger
6,8001732
6,8001732
I missed that bit of the tar documentation. I tried it and it didn't help. Note thatarchivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.
– Luke Skywalker
2 days ago
1
@LukeSkywalker Looking at the code, it doesn't seem likearchivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references tod_type
either, so it seems it doesn't implement that either...
– Filipe Brandenburger
2 days ago
add a comment |
I missed that bit of the tar documentation. I tried it and it didn't help. Note thatarchivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.
– Luke Skywalker
2 days ago
1
@LukeSkywalker Looking at the code, it doesn't seem likearchivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references tod_type
either, so it seems it doesn't implement that either...
– Filipe Brandenburger
2 days ago
I missed that bit of the tar documentation. I tried it and it didn't help. Note that
archivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.– Luke Skywalker
2 days ago
I missed that bit of the tar documentation. I tried it and it didn't help. Note that
archivemount
man page also mention extended attributes, but only for MacFUSE. I don't know if it means that they enabled by default on linux or they are just not supported on linux.– Luke Skywalker
2 days ago
1
1
@LukeSkywalker Looking at the code, it doesn't seem like
archivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references to d_type
either, so it seems it doesn't implement that either...– Filipe Brandenburger
2 days ago
@LukeSkywalker Looking at the code, it doesn't seem like
archivemount
supports extended attributes, since the functions that would implement them are commented out. Looking at the code, there are no references to d_type
either, so it seems it doesn't implement that either...– Filipe Brandenburger
2 days ago
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486946%2foverlayfs-over-archivemount%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown