Linux block device simulation & Fuse - linux

My project involves simulating a block device by remote host.
For testing I am using FUSE, my file system is a simple change of the "hello" example app, where instead of returning a constant string I just read data directly from a file.
When I try to mount the file normally (mount -o loop=/dev/loop1 ) it works well.
When I load fuse and expose this file via it, all the normal file operations work. But mounting fails with "Permission denied".
Anyone has an idea where the "permission denied" is coming from ?
Any other methods to that will allow me to create a virtual device (only support block access) in users space, that will be mountable ?
Thanks in advance

Presumably the problem is that the FUSE filesystem doesn't support the features required to have loop-mounts on it.
Have you considered using a network block device instead, such as NBD or iSCSI target?

Are you executing with Root permission. You can trace the program with "strace" and then check where exactly this fails.

The mount command is a real hell to use when it starts to print errors. Try "-v" but more often than not, the additional output won't help :(

Related

Setcap is not working for raw sockets on custom distro

I'm in the process of building a small linux distro based on Debian for automated network testing. I am running into a pretty annoying problem though. A number of applications like paris-traceroute, ping, dublin-traceroute and so forth are not working correctly. They return an error of being unable to open a raw ICMP socket. I have tried using 'setcap cap_net_raw+ep ./application' and it's not working even though getcap indicates that the bits have been set.
I'm also running into the same problem if I try to use them as setuid root. They only work under sudo. So I'm wondering if I screwed up permissions on some intervening library or if there is some other issue.
Anyone run into something like this or have a solution?
Thanks!
In case anyone comes across this I'll explain why this is failing.
What I didn't mention is that the applications (like ping, etc) are actually installed in /opt. In this distro /opt actually and encfs file system that is only mounted after the livecd has been authorized against a licensing type of server (there are valid reasons for this - it automatically tests network connections and send the results to network engineer. We only want it to run within a specific time frame that would be associated with the user trouble ticket). So /opt isn't a real filesystem - it's an encrypted file mounted via fuse to looks like a file system. As such setcap and setuid don't actually work and likely cannot work.

Device mapper, boot with virtual device

I have a task to make a virtual device under a real one with the help of device mapper kernel module. Virtual device must transfer any request to a real device, so both devices must be equal.
In prospective I should be able to control requests, so I wrote kernel module, representing device mapper target, using this article.
After making module and inserting it (insmod command) I setup my device (dmsetup create). Then do mount and can work with a real device through just created virtual.
But the question is how to repeat above mentioned instructions in boot time? I'd like to use my virtual device as a general one (by changing fstab, I guess).
Thanks in advance!
If you are going to use your device as the root filesystem, you need to create an initramfs that sets it up. Basically a shell script that issues dmsetup commands, followed by a mount and finally pivot_root to the new filesystem.
There was a discussion on the dm-devel mailing list last year on how to do this in the Linux kernel without an initramfs, by specifying mapper lines on the kernel command line. This is they way Chrome OS does it, because they can't/won't use an initramfs. See here for documentation of this feature. The functionality was never merged though.
The patch series was updated and resubmitted in May 2017. Hopefully we will eventually see it merged in some form or other.
If you are not going to use your device as the root filesystem, you can still use the same approach if you want, but there might be easier ways.

Starting Gnome 3 in a read-only environment

First off, my intention is to create a portable, bootable USB drive containing a GNU/Linux distribution. Specifically, I want to use Arch Linux with a squashfs read-only root filesystem.
The squashfs image is based on a snapshot of a working VM. The base system with it's services like ssh work out of the box as expected. But when trying to launch gnome via systemd (systemctl start gdm), all I see is a black screen (supposedly the X-Server started but gdm fails to load). I already tried to figure out whats happening, but failed to identify the exact problem.
Home directories are writeable
/tmp is writeable
/var/log is writeable
/var/run & /run are writeable anyway
/var/log/gdm gets created but stays empty.
Which modules may require write access to any other files? Is there any documentation? What would make sense to strace or similar?
My desire is to know the root of the problem and fix it, instead of using workarounds like unionfs. Thanks for any help or hints!
Although it's not relevant, for those who might wonder why I want to do this, here are some points to consider:
Stability - as you cannot modify system files, you cannot mess up the system (unless you write bogus directly to the drive of course)
Storage - as files are compressed, more data fits on the drive
Performance - as I/O on most USB drives is slow, compression gives you higher I/O speed
Portability - no special treatment for read-only storage, you might copy it on a CD or any other read-only technology and it will still work the same way as it would on a writeable disk
Update
I figured out that the problem was actually at /var/lib/gdm. GDM tried to access files in there an (silently) failed doing so giving me a black screen.
I figured out that the problem was actually at /var/lib/gdm. GDM tried to access files in there an (silently) failed doing so giving me a black screen.
journalctl was the debugging command i was missing in the first place.

aoe disk as /dev/sda in /proc/partitions

Im using AoE disk for a particular Linux installation.
I need to tell to linux system to see /dev/etherd/e0.0 as a /dev/sda,
im already create a hard link of /dev/etherd/e0.0 to /dev/sda an it works.
But now i need to make system see the /dev/sda (/dev/etherd/e0.0) in /proc/partitions.
There exists a command to do that ?
thank you.
There is no way to do that. The /dev/sda node is reserved for devices which are accessible using the SCSI/SATA/IDE disk driver; AoE devices do not use that mechanism, so they will always show up differently. Creating a hard link will just confuse matters; doing so is inadvisable.
I'm not 100% certain whether it's even possible to boot a machine over AoE. It might be possible to do directly if all the configuration is automatic, or can be performed by setting kernel command line parameters; chances are that you will need to create a custom initrd to initialize the network and bring up the volume.

Read system call for a file residing on a smb mount hangs forever if network connection is broken?

I have mounted a windows shared folder on a centos box. When i try to read a huge file using read system call and if network connection breaks then the read simply hangs and puts my program into a uninterruptible sleep state. This does not sound right. Even if i open the file using O_NONBLOCK even then the read does hang. I was hoping that read will eventually time out but it does not.
How do you implement a reliable copy operation over network if the read is simply going to block without returning any error?
I dont think the using async mode And select call is going to help me either.
Is read always a blocking call?
Thanks
Ghanaku
You could try mounting the remote filesystem as cifs instead of smb. mount.cifs supports the soft options (and it is the default too) that will cause an error to be returned in the case of a network or server failure instead of a hang.
From the man page:
soft: (default) The program accessing a file on the cifs mounted file system will not hang when the server crashes and will return errors to the user application.

Resources