Followed this MagPi tutorial to make a smart flash drive: Having some trouble with mount/umount

[pauljlamp]

Hello all,

I am a relatively new Raspberry Pi user, following this tutorial, using a Raspberry Pi Zero W and Raspbian Stretch.
https://www.raspberrypi.org/magpi/pi-ze ... ash-drive/

It seems to be working fine. I didn't complete steps 13 and 14 because they don't apply to my project, but I do understand them. An important difference with my project is that the device that the Raspberry Pi is plugged into, is making changes to the files, instead of being read only. For this example, I have it plugged into my phone and then copy pictures on my phone to the "flash drive".

However, the Samba network share does not update with new changes unless I mount and and un-mount the "/mnt/usb_share" directory (using mount and umount). Rebooting also works, probably because everything is unmounted and mounted during the process.

Nothing else I have tried succeeds in getting the new changes to refresh in the network share. Originally I spent a lot of time thinking the problem was Samba, so I added options in the smb.conf file (such as oplocks=no, and csc policy=disable) to troubleshoot, as well as rebooting services related to Samba (smbd.service, nmbd.service, winbind.service) after making a change to the "flash drive" from my phone.

Code: Select all

sudo modprobe g_mass_storage file=/piusb.bin stall=0 ro=0 removable=1
sudo modprobe -r g_mass_storage

These lines, used to activate and deactivate the usb mode of the Raspberry, did not work either, the network share did not update with new changes. The program written for the tutorial in step 14, http://rpf.io/usbzw, primarily uses these commands, but I wasn't having any luck getting them to refresh the network share.

As I stated before, the only action that succeeded was mounting and un-mounting the directory in question, with "mount" and "umount". I looked into the documentation for these commands to figure out what they were doing that successfully made the changes appear, but all I could really determine was that some level of syncing was occurring before the un-mount took place. However, the actual "sync" command also failed to refresh the network share.

I don't really want to be constantly dismounting and mounting the directory in use, I would rather just figure out how exactly those two commands are succeeding in syncing the files I have changed. And that is the core of my question, why does "sync" not work in this scenario, and why do "umount" and "mount" work?

Thank you for your help. I've tried to be detailed in my post, but please let me know if you need any more information.

[thagrol]

It's a limitation of the mass_storage gadget.

There is no notification from one side to the other when a change takes place so the only way to update the side that didn't make the change is to unmount and remount the drive.

It also means that it's a very bad idea to have write access from both sides at the same time. And potentially problematic to have it from one side only.

Both sides (Pi and USB host) expect low level access to the storage and both use caching so you can run into all sorts of issues when changes are made.

That tutorial is unsafe if changes are being made from both sides and insecure, though that may not matter to you. It also has the potential for being extremely annoying (someone updates the storage when you're watching a movie, or worse deletes the file you're watching).

It's insecure as unseen changes can result it deleted data being visible to the other side of the link, it's dangerous as you could get random data passed to your output device with the possibility of damaging it.

That turorial has some basic protection as it exports the storage passed to the gadget as read only so as to prevent changes from that end. To duplicate that you'll ned to mount the storage on the Pi as readonly. Modifying that tutorial gives an fstab entry like this:

Code: Select all

/piusb.bin /mnt/usb_share vfat ro,users,umask=222 0 2

Unfortunately, unless the USB host can monitor for changes to the filesystem and then run scripts on the Pi you can't get automatic updates(via umount/mount) on that end.

[thagrol]

And that is the core of my question, why does "sync" not work in this scenario

Because the linux filesystem drives don't know about the changes made by the USB host so don't have anything in their buffers to sync.

and why do "umount" and "mount" work?

Because umount then mount forces the drive/file/partition to be reread.

[pauljlamp]

Okay then... thank you. That was very helpful and I appreciate the response.

My current goal is to allow changes from the USB end only. However, I would like to see and likely copy the files from the network share, at a semi-regular interval. So the USB side (the device that is using the Raspberry Pi like flash drive) is the side that needs write access.

Can I make it only read only from the Pi side, and will that put me in a better position as far as security/safety? Can I copy a file from a read only data source? Is that the purpose of the code you posted?:

Code: Select all

/piusb.bin /mnt/usb_share vfat ro,users,umask=222 0 2

Do you have any other suggestion or resources I might be able to look at it in order to improve the security of the process? Unfortunately the USB host is going to be somewhat dumb, and won't be able to run scripts on the Pi. I was considering just running umount/mount at an interval, and I think the intended host for the device will not try to write unless it detects a connected USB.

Thanks again, you've already been very informative.

[thagrol]

Yep, that code snippet is to make the Pi treat the USB gadget storage as read only. "ro" in the mount options tells the Pi to mount it read only. "umask=222" sets permission so that write access on files and directories is not present.

You can copy files from read only mounts etc, you just can't write to them.

Unmounting and re-mounting the storage on the linux (pi) side won't affect the USB host, nor will copying files from it. But fiddling with the g_mass_storage module will.

The danger is that when copying files you may get incomplete or wrong data if files are being written at the same time as the copy. Or if the SD card/USB host is doing any housekeeping.

The safest way is to only have the storage mounted on one side at a time. However with a dumb host there is no way to do this automatically, or at least no way without risking corruption. The host may be writing to it when you remove it. Think of it as yanking a USB stick midway through a write.

If you've looked at their script you'll have seen that it loads and unloads the g_mass_storage module to force updates. You don't need to do this as you won't be writing to it from the linux side. But if you want to remove it when copying files, there is a better way:

Load g_mass_storage like this:

Code: Select all

modprobe g_mass_storage file=/piusb.bin stall=0 ro=1 removable=1

This makes it appear to the host as a device with removable storage (think CD-ROM).
To remove storage from the host:

Code: Select all

sudo echo "" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

To give it storage:

Code: Select all

sudo echo "/piusb.bin" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

Check those paths though. They may be different on a Zero or ZeroW and I can't remember which I wrotre that on.

[pauljlamp]

Okay, I'm learning a lot. Your reply answered my questions pretty succinctly.

However, I'm not sure what the purpose of unloading and loading using these commands:

Code: Select all

sudo echo "" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

Code: Select all

sudo echo "/piusb.bin" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

I checked the paths, and they appear to correct... as in, the files do exist, I'm not sure if they are right ones. When I attempt to run the command, I get a "permission denied". Do you know why I'm getting this error, and can you further explain what is the purpose/benefit of using these commands?

Thank you.

[thagrol]

The purpose of those two commands is to prevent the USB host writing to the storage whie you're copying from it.

The first one tells g_mass_storage that it no longer has somewhere to read from/write to so the USB host sees an empty drive. Think of it as pressing eject on a USB DVD drive and removing the disk.

The second one tells it where its storage is. Think of it as inserting a DVD and closing the drive tray.

Not sure why you're getting a permission denied error but:

• Did you run those commands as root or with sudo?
• Did you load g_mass_storage with removable=1?
• If you had previously loaded g_mass_storage did you remove it first?

  Code: Select all

  sudo rmmod g_mass_storage

[pauljlamp]

Did you run those commands as root or with sudo?
Did you load g_mass_storage with removable=1?
If you had previously loaded g_mass_storage did you remove it first?

1. I ran them with sudo
2. Yes
3. When you say "previously loaded g_mass_storage", do you mean with:

Code: Select all

modprobe g_mass_storage file=/piusb.bin stall=0 ro=1 removable=1

If so, yes it is loaded. If I remove g_mass_storage with "rmmod" or "modprobe", then instead of getting permission denied, I get "file does not exist." Should g_mass_storage be loaded? I thought yes, because my understanding is that:

Code: Select all

sudo echo "" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

is a better way of preventing the USB host from writing while I'm copying files, versus unloading "g_mass_storage".

From very basic research it looks like "permission denied" is a common troubleshooting problem, so maybe I will have to figure this one out.
Thanks.

[thagrol]

Sorry wasn't clear.

What I mean was that was g_mas_storage had already been loaded when you ran that modprobe command? Trying to modprobe an already loaded module doesn't do anything. It just silently exits.

Try this:

Code: Select all

sudo rmmod g_mass_storage
sudo modprobe g_mass_storage file=/piusb.bin stall=0 ro=0 removable=1

Then those echo commands

Note: you need ro=0 not ro=1 otherwise the USB host won't be able to write to it.

Edit: the g_mass_storage module does need to be loaded for those files/folders to be present.

[pauljlamp]

Alright, I think we are on the same page then, I was understanding you correctly.

Unfortunately, I'm still getting a "permission denied" after following those steps correctly.

I will update this post if I am able to find a solution. It isn't critical to making progress on this project, but I sure would like to be able to use those commands.

[eckirchn]

Have you had any luck with this? I would like to copy files off a DVR as they are written, but the only way I can think of is to disable SAMBA, umount, remount, enable SAMBA periodically, which though it wold work it's far from ideal.

[thagrol]

Have you had any luck with this? I would like to copy files off a DVR as they are written, but the only way I can think of is to disable SAMBA, umount, remount, enable SAMBA periodically, which though it wold work it's far from ideal.

That's about the only way. The trick is in knowing when the DVR has finished writing each file...

[hippy]

Unfortunately, I'm still getting a "permission denied" after following those steps correctly.

A bit late in the day, but if you mean these -

Code: Select all

sudo echo "" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file
sudo echo "/piusb.bin" > /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

They need to be refactored -

Code: Select all

echo "" | sudo tee /sys/devices/platform/soc/20980000.usb/gadget/lun0/file
echo "/piusb.bin" | sudo tee /sys/devices/platform/soc/20980000.usb/gadget/lun0/file

But I haven't seen any advantage in doing it that way over "sudo modprobe g_mass_storage ..." and "sudo modprobe -r g_mass_storage". They seem to be equivalents.

Have you had any luck with this?

Not me. I have a very simple set-up; Pi Zero generates an image of a clock which it updates every minute to share out to a digital picture frame. Despite the Pi side being write-only, the DPF read-only, having no caching and re-reading the entire directory when it looks for an image to display, I am still having issues when the Pi writes as the DPF is reading.

I have tried many things to avoid unsharing the gadget backing file store, double-buffering files, saving images as files the DPF doesn't understand then renaming them so the directory remains correct while the files change, the directory list only changing for the briefest of time, so it should display something without error no matter what it's doing and when things change but that doesn't work; I still see the DPF get confused, corrupt images, hang or stall.

The only thing which probably would help is to change when the files and directory are updated to just after the DPF has read the directory and file, but I have not found a way to do that, and think I may have to revert to actually monitoring the USB D+/D- lines on separate GPIO pins, rewriting the g_mass_storage gadget driver, using sector access to the backing store rather than file access.

And, it's even worse when there is read-write access from one or both sides, especially with caching going on which is in what's connected, not in the Pi itself.

It's on par with standing outside a library while an invisible and silent ninja sneaks in the back, adds and removes books, adds and removes pages from books. It's impossible to tell that's happened without going in to check what's changed, and impossible to know if they've finished adding or removing books, adding or removing pages of any particular books without a level of caching and analysis which doesn't exist.

Even worse when both sides have arbitrary read-write access.

Bottom line for me, as others have discovered themselves, is that I don't believe it can be done 'perfectly' with g_mass_storage gadget. One needs to unmount/mount, unshare/share, to see or let the other side know something has changed, make changes in a way which doesn't bork the other side.

This is why Android and other systems have moved away from MSD to MTP and other protocols.

[thagrol]

Ultimately, we're all trying to do something the USB mass storage device class and block devices in general were never intended to do:concurrent access from multiple masters.

Now, a cluster aware filesystem can probably solve this but that's very niche and most of the posts around this topic want FAT32 which definitely isn't cluster aware.

About the only safe way I've found to pass writes from one side to the other is to manually unmount from the writing side forcing all buffers to be written to disc before unmounting and remounting only on the non-writing side. Once you've read/copied the new data unmount on the reading side and remount on the writing side.

If you're doing it by hand, unless there is no physical access to the devices you might as well be using sneakernet.

Sure, you can force unmounting the USB gadget from the USB host (rmmod or sysfs) but you have absolutely no idea when it's safe to do so. Even with write caching disabled on the USB host, it cannot be assumed that the last block written was the final one.

g_mass_storage has it's uses (e.g infrequent content updates, composite devices with drivers provided onboard to name two) but the risks and complications are too great for it to be used for live data transfer in anyway other than read only on all devices.

That said, if you've got the full OS source code for both the USB host and raspbian along with the neccessary skills...

[ncs077]

I have a related follow up question. I have a digital photoframe (Aluratek Model #ADPFD10F) that has a USB input to display photos from a flash drive. I thought this would be a good opportunity to begin working with the g_mass_storage module. Similar to the OP I followed the MagPi tut. In fact the tutorial worked perfectly for me. I could hook the pi up to my tv and view the photos. I could change the photos through the shared folder and the pi would auto disconnect from the tv and then reconnect after a few moments of inactivity and would indeed display the changes I had made. I could reproduce the results on my laptop (Ubuntu 18.04) as well. Plug in the pi and it was viewed as a flash drive. This success however, was not reproducible on the photo frame. The frame recognized there was a usb device attached but it claimed there were no files on it. I tried some of the changes recommended above but have to admit I'm in a little over my head now. Can anybody provide any explanation as to why the photo frame seems to be the only thing that doesn't see any files? Any suggestions on how to proceed if possible at all? Thanks in advance

[thagrol]

Nothing specific springs to mind and a quick websearch didnt' reveal anuy usefuls specs on that device.

So the only advice I have is for the general case:

• Does your photoframe support the filesystem you're using?
• Does it support the file types you're using?
• Does it expect the files to be in a particular directory structure? I have device that will only see files on the USB device if they're in a subdirectory rather than the root of the device, some that will see files anywhere, and some that will only see them if they're in a correctly named subdirectory.

[hippy]

Can anybody provide any explanation as to why the photo frame seems to be the only thing that doesn't see any files? Any suggestions on how to proceed if possible at all?

Photo frames can be quite fickle. One problem can be that when they boot up, and they don't immediately see the Pi as an MSD device but as something else, they throw in the towel.

What I would suggest is booting vanilla Raspbian with the dwc2 drivers loaded but not g_mass_storage, create a FAT32 file system to share, put some photos on it, then manually share it out -

sudo modprobe g_mass_storage file=/msd.bin stall=0 ro=0 removable=1

Then power-up the photo frame after that. It should hopefully then see something which is definitely and immediately an MSD device when it boots.

If it is a photo frame boot up issue, not seeing the Pi as MSD, it may be worth unmounting and re-mounting the MSD file system. That works for various frames I have which do not work otherwise.

You may have to unmount and remount the file system whenever it is changed. The frames I have all eventually corrupt their displays, hang for long periods and so on, if I update the file system without doing that.

[hippy]

[*]Does it support the file types you're using?

Good point. Nearly all of mine only recognise JPG files, not BMP, GIF or PNG. Also try with images which are small or moderatly sized to start with because not all will handle large megapixel sized files. Get something working then set about finding its limitations.

[thagrol]

You may have to unmount and remount the file system whenever it is changed. The frames I have all eventually corrupt their displays, hang for long periods and so on, if I update the file system without doing that.

If memory serves the approach in the tutorial does just that from the Pi side. Won't hurt to do so again from the frame's side though.

And if the frame doesn't see/do an unmount followed by a mount after the changes are made it won't see them. That's due to limitations in g_mass_storage and part of why I don't like the approach that tutorial uses.

Edit: fixed a couple of typos.

[ncs077]

Thank you both for your quick replies! A quick extra tidbit and then addressing some of your comments. I have tried the same exact photos on a real (Sandisk 32 GB) flash drive. It works no problem on the frame.

Nothing specific springs to mind and a quick websearch didnt' reveal anuy usefuls specs on that device.

So the only advice I have is for the general case:

• Does your photoframe support the filesystem you're using?
• Does it support the file types you're using?
• Does it expect the files to be in a particular directory structure? I have device that will only see files on the USB device if they're in a subdirectory rather than the root of the device, some that will see files anywhere, and some that will only see them if they're in a correctly named subdirectory.

- I am using FAT32 and it is what the frame requests (FAT32 both on the piusb.bin and the sandisk flash drive)
- I am using jpegs and it does indeed support those (the same exact images were used for both the pi and the sandisk drive)
- Since I can only test working directory structures with the sandisk drive I've found that no particular structure seems to be necessary. I've tried both burying photos throughout a folder structure and leaving just the image files at the root and the frame found all the photos in both instances and displayed them all.

Now that being said....as another experiment I tried partitioning my sandisk drive into two separate partitions. I put images on both partitions. ONLY the images from the first partition on the drive showed up. To further test this I then deleted all the images on the first partition but left the images on the second. Upon reinserting the sandisk drive to the frame I got an error message saying "No File Found". Now it is possible that this is the standard error message that comes from the frame in any sort of circumstance but it does just happen to be the same error I got with the pi. I'm not sure if this is important new information or a red herring.

Can anybody provide any explanation as to why the photo frame seems to be the only thing that doesn't see any files? Any suggestions on how to proceed if possible at all?

Photo frames can be quite fickle. One problem can be that when they boot up, and they don't immediately see the Pi as an MSD device but as something else, they throw in the towel.

What I would suggest is booting vanilla Raspbian with the dwc2 drivers loaded but not g_mass_storage, create a FAT32 file system to share, put some photos on it, then manually share it out -

sudo modprobe g_mass_storage file=/msd.bin stall=0 ro=0 removable=1

Then power-up the photo frame after that. It should hopefully then see something which is definitely and immediately an MSD device when it boots.

If it is a photo frame boot up issue, not seeing the Pi as MSD, it may be worth unmounting and re-mounting the MSD file system. That works for various frames I have which do not work otherwise.

You may have to unmount and remount the file system whenever it is changed. The frames I have all eventually corrupt their displays, hang for long periods and so on, if I update the file system without doing that.

Thanks for this tip I will give it a shot as soon as I get home from work. Again thank you so much for your continued help! I mean who wants to sneakernet photo updates these days!

[thagrol]

Now that being said....as another experiment I tried partitioning my sandisk drive into two separate partitions. I put images on both partitions. ONLY the images from the first partition on the drive showed up. To further test this I then deleted all the images on the first partition but left the images on the second. Upon reinserting the sandisk drive to the frame I got an error message saying "No File Found".

That's very possibly the cause. Another possibility is whether teh storage space on the Pi ahs an MSDOD or GPT partition table.

At a guess, it's highly possible that the frame will only look at the first partition. After all for most consumers the likelyhood is that there will only be one partition on the drive. Equally, unless you're talking about very large devices I'd expect MSDOS rather than GPT partition tables.

Another posibility is that whatever created and formatted your shared storage didn't create the partition table correctly, or at all.

Something to try:

• Create a new empty storage area. Do not partition it or format it.
• Plug the pi into a windows PC with the storage exported via g_mass_storage. Do not have it mounted on linux at this time (you probably won't be able to anyway)
• Use Window's tools to partition and format that storage. If given a choice, opt for an MSDOS partition table not a GPT one.
• Either copy image files on to it from windows or do it from linux but do so when the storage is not connected (let alone mounted) to the frame.

It's probably the frame's software at fault. It will have been made to a budget with certain assumptions in mind.

[ncs077]

Well I'd like to thank you both. The frame still recognizes the usb device is there but still also finds no files.

What I would suggest is booting vanilla Raspbian with the dwc2 drivers loaded but not g_mass_storage, create a FAT32 file system to share, put some photos on it, then manually share it out -

sudo modprobe g_mass_storage file=/msd.bin stall=0 ro=0 removable=1

Then power-up the photo frame after that. It should hopefully then see something which is definitely and immediately an MSD device when it boots.

If it is a photo frame boot up issue, not seeing the Pi as MSD, it may be worth unmounting and re-mounting the MSD file system. That works for various frames I have which do not work otherwise.

You may have to unmount and remount the file system whenever it is changed. The frames I have all eventually corrupt their displays, hang for long periods and so on, if I update the file system without doing that.

I started from scratch as you suggested Hippy and followed these steps but alas...still no pictures.

Something to try:

• Create a new empty storage area. Do not partition it or format it.
• Plug the pi into a windows PC with the storage exported via g_mass_storage. Do not have it mounted on linux at this time (you probably won't be able to anyway)
• Use Window's tools to partition and format that storage. If given a choice, opt for an MSDOS partition table not a GPT one.
• Either copy image files on to it from windows or do it from linux but do so when the storage is not connected (let alone mounted) to the frame.

I also did this Thagrol but still no pictures. I'm afraid Thagrol is probably right in saying this:

It's probably the frame's software at fault. It will have been made to a budget with certain assumptions in mind.

Thank you both again. I will post back here if I stumble onto something else and appreciate any more insights you may have in the future.

[hippy]

It is odd that the frame appears to recognise the USB being connected but not find the photos. Of the 20 or so frames I have only a Kodak EasyShare SV710 has proved problematic, and that doesn't recognise the Pi as connected at all. All the rest have shown photos served up by the Pi.

The main issue has been what they do when the mass storage file system is pulled before being shared out again. Some don't, or only rarely, put up a 'selection/setup' screen, some always do, some for longer than others and are more obtrusive, and a few won't go back to selecting the USB unless a button is pushed.

Perhaps you have just got unlucky. The only other thing I could suggest, if powering the Pi from its own PSU, is to cut the power wire in the USB cable from the Pi to the frame if you haven't already. I'm not convinced it would help though. It does sound like a software issue with respect to the frame.

[thagrol]

While simpler than more modern filesystems FAT has it's own complexities. One that might trip things up is that it is possible to have two copies of the acutal File Allocation Table.

In which ase it's possible that the writing device only update one of them and the reading device only reads one of them. If the don't both use the same table they'll see different things.

To be honest, unless you have a problem with physical access to the frame or have a large number of devices that need frequent updates from a central location you'll get more reliable results using the frame as it was intended: with a "real" USB stick.

Using g_mass_storage this way (or the way I've previously proposed - look me up on instructables) is a hack. And an ugly one at that.

[TURMIRE]

Well I'd like to thank you both. The frame still recognizes the usb device is there but still also finds no files.

What I would suggest is booting vanilla Raspbian with the dwc2 drivers loaded but not g_mass_storage, create a FAT32 file system to share, put some photos on it, then manually share it out -

sudo modprobe g_mass_storage file=/msd.bin stall=0 ro=0 removable=1

Then power-up the photo frame after that. It should hopefully then see something which is definitely and immediately an MSD device when it boots.

If it is a photo frame boot up issue, not seeing the Pi as MSD, it may be worth unmounting and re-mounting the MSD file system. That works for various frames I have which do not work otherwise.

You may have to unmount and remount the file system whenever it is changed. The frames I have all eventually corrupt their displays, hang for long periods and so on, if I update the file system without doing that.

I started from scratch as you suggested Hippy and followed these steps but alas...still no pictures.

Something to try:

• Create a new empty storage area. Do not partition it or format it.
• Plug the pi into a windows PC with the storage exported via g_mass_storage. Do not have it mounted on linux at this time (you probably won't be able to anyway)
• Use Window's tools to partition and format that storage. If given a choice, opt for an MSDOS partition table not a GPT one.
• Either copy image files on to it from windows or do it from linux but do so when the storage is not connected (let alone mounted) to the frame.

I also did this Thagrol but still no pictures. I'm afraid Thagrol is probably right in saying this:

It's probably the frame's software at fault. It will have been made to a budget with certain assumptions in mind.

Thank you both again. I will post back here if I stumble onto something else and appreciate any more insights you may have in the future.

Strangely enough, I had a similar situation with a device and fat32 file system. With my device it turned out to be 0xb vs oxc on the host device (LBA vs non LBA) and partition offset.
I'm kinda curios as to whether or not this possibly solves your problem with the photo frame. When you get a chance try this, however just not it involves formatting on a host windows machine using guiformat. Here are the steps in order.
1. setup your bin file, ill call it usb.bin and place it in root for this example.
2. sudo fdisk /usb.bin
3. add partition by selecting n
3. make it primary by selecting p
4. it asks what partition number, select 1
5. It asks for starting sector, just hit enter for default. I believe it will be 2048.
6. It asks for last sector again just hit enter for default. It will now say "Created a new partition 1 of type 'Linux' and of size #### MiB.
7. change partition type by selecting t (It should say "selected partition 1 Hex code (type L to list all codes): )
8. enter c (it should say Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'. )
9. enter w (this writes in the changes you just made and should say "The partition table has been altered. Syncing disks." )
10. connect to the windows host sudo modprobe g_mass_storage file=/usb.bin stall=0 ro=0 removable=1
11. format using guiformat on the host windows pc. It can be found here http://www.ridgecrop.demon.co.uk/index. ... format.htm
12. Now mount the drive on the pi with the offset which is based of the 2048*512, which I mentioned on step 5. If your starting sector is different just adjust accordingly. Based on a starting sector of 2048 the command to mount would be:
sudo mount -o loop,offset=1048576 /usb.bin /your mounting point
13. If you wanted to mount from your fstab with the same starting sector of 2048 you would place the following in fstab
/usb.bin /mountpoint vfat loop,offset=1048576 0 2
Make sure to double check that it mounts from the fstab with sudo mount -a before rebooting

Let me know if this resolved the issue.