Help! - fuse and loopback - not working together

[Greg Freemyer]

All,

I don't know if this is a kernel issue or not. I just don't know
where else to look for help.

I seem to be having a conflict between fuse and loopback devices. I
can get each to work fine independently, but I can get them to work
together. This has worked with older kernels, but I can't get it to
work with a 3.16.6 kernel.

I'm just guessing the issue is a kernel issue. I really don't want to
have to compile kernels to track this down, but it may come to that.

All userspace tools I'm using are opensource, so I dod have the
userspace source to work with, although I'm not the author.

=====
I'm trying to use a tool (ewfmount) that leverages the fuse kernel
sub-system to merge several files together and also uncompress them.

Thus I might originally have:

image.E01
image.E02
image.E03

where each of those files is a segment of full dd image that has been
compressed.

If I run "ewfmount image.E01 /mnt" then a virtual file /mnt/ewf1 is
created. That is working fine.

In the past I have been able to now loopback mount partitions from
that virtual file via:

mount -t hfsplus -r -o loop,offset=209735680 /mnt/ewf1 /mnt

Currently that is failing with:
mount: /mnt/ewf1: failed to setup loop device: Permission denied

Thus loop back seems broken. To test that I copied the virtual file
to a real file via dd. After that mount properly accesses the true
file.

===
Thus:

fuse is working right to merge my files together and uncompress them.

loopback is working right when the object being mounted is a standard file.

loopback is failing when pointed at the virtual file created by fuse.
===

I am suspicious of the kernel because this has worked for me in the
pastk but with older kernels. I can't say when it last worked, but at
least a year ago.

Any suggestions / help appreciated.

Thanks
Greg
--
Greg Freemyer

[Greg Freemyer]

The issue is that I was running the fuse mount command as a normal
user and mount as root.

By default fuse does NOT allow root to access filesystems it creates
unless root created them.

For me there are 2 work-arounds:

- Add sudo in front of my command creating the filesytem

- Set an option in /etc/fuse.conf to allow none-owners of a filesystem
to use the filesystem.

I suspect when I did this in the past I was running as root, so I
never noticed the problem.

Sorry for the noise,
Greg
--
Greg Freemyer

Post by Greg Freemyer
All,
I don't know if this is a kernel issue or not. I just don't know
where else to look for help.
I seem to be having a conflict between fuse and loopback devices. I
can get each to work fine independently, but I can get them to work
together. This has worked with older kernels, but I can't get it to
work with a 3.16.6 kernel.
I'm just guessing the issue is a kernel issue. I really don't want to
have to compile kernels to track this down, but it may come to that.
All userspace tools I'm using are opensource, so I dod have the
userspace source to work with, although I'm not the author.
=====
I'm trying to use a tool (ewfmount) that leverages the fuse kernel
sub-system to merge several files together and also uncompress them.
image.E01
image.E02
image.E03
where each of those files is a segment of full dd image that has been
compressed.
If I run "ewfmount image.E01 /mnt" then a virtual file /mnt/ewf1 is
created. That is working fine.
In the past I have been able to now loopback mount partitions from
mount -t hfsplus -r -o loop,offset=209735680 /mnt/ewf1 /mnt
mount: /mnt/ewf1: failed to setup loop device: Permission denied
Thus loop back seems broken. To test that I copied the virtual file
to a real file via dd. After that mount properly accesses the true
file.
===
fuse is working right to merge my files together and uncompress them.
loopback is working right when the object being mounted is a standard file.
loopback is failing when pointed at the virtual file created by fuse.
===
I am suspicious of the kernel because this has worked for me in the
pastk but with older kernels. I can't say when it last worked, but at
least a year ago.
Any suggestions / help appreciated.
Thanks
Greg
--
Greg Freemyer