External USB drive Formatted exfat plugged into Raspberry Pi 3b NOT mounting

UPDATE: Command line work indicates the FUSE module is not installed on my Max2Play RPi-3B system, therefore though the USB drive is detected it’s exFat filesystem is not accessible. „apt install fuse“ does not really work, error message says the latest version is already available but then says it has to be manually installed. This is unfortunate.

Anyone have experience installing FUSE manually ? Purging FUSE, then reinstalling does not work. Most things I am discovering that were annoying under Linux are even more so on Pi Linux. Difficult to sell into a mainstream market with that fact in effect.

• This reply was modified 2 years, 2 months ago by Mark-in-Seattle_GMT8.

@MarioM — Thank you very much for your response. (there is a problem with the Max2Play forum posting software not allowing edits to posts)

Yes indeed, I had tried the commands you suggested via VNC login and root terminal:
„sudo apt-get install exfat-fuse“
„sudo apt-get install exfat-utils“

Both commands generated errors indicating exfat-fuse was already installed as the latest version and would not be updated, however another puzzling error message implied that exfat-fuse required manual installation, which I was not able to do. Command „modprobe fuse“ indicated the fuse module was either not in the kernel or not loaded(?) Very confusing.

Due to the above cited problems, I have abandoned exFAT as the external USB drive filesystem and am now trying to use FAT32 (vfat) which should be builtin since the small /boot(?) partition is listed in fstab as type = „vfat“, but without success. Have NOT gotten Max2Play (latest version) to see the MP3 music file contents of the external drive, which is externally powered using it’s own 5vdc supply, when attached to any of the RPi’s 4 USB ports. Also tried external drive without using it’s power supply.

I can use terminal commands (blkid) to discover the external USB drive’s status: /dev/sda1, Label=“FAT32-512GB“ (my correct drive label), UUID=51e2-4430 (correct after reformatting as FAT32), type=vfat, PARTUUID=1fb0946c-01 (reasonable). This has become quite frustrating…. an external FAT32 formatted USB SSD drive, with it’s own powersupply, can not be read even though during RPi boot process linux can recognize important information about the same drive: UUID, label, type=vfat …etc.

My goal was simply to attach a known to be working USB SSD drive holding my MP3 music library to the Max2Play Raspberry Pi-3b thru any of the RPi-3b USB ports so Squeezebox Server could use a locally attached music library. This had worked before a couple years ago using the same USB SSD drive formatted as EXT4. Once attached and configured to automount in fstab (using UUID source label mounted to a local folder…) was able to copy my music library from my Hackintosh over the local network to the RPi-Max2Play. Worked well, played music fine.

This time I wanted to copy my music library directly to the same USB SSD formatted with a filesystem (exFAT or FAT32) that was compatible with MacOS and Max2Play-RPi. Seemed reasonable, however as outlined above I can not get the Max2Play to see the contents of the USB SSD drive formatted as FAT32 at all. My assumption is: if the external USB drive is attached and using /etc/fstab mounted to /mnt/usbdrive/ then I should be able to see the contents of the USB drive by looking in directory /mnt/usbdrive/

FSTAB
Here is my /etc/fstab file:

proc /proc proc defaults 0 0
PARTUUID=ee397c53-01 /boot vfat defaults 0 2
PARTUUID=ee397c53-02 / ext4 defaults,noatime 0 1

##USERMOUNT
UUID=51e2-4430 /mnt/usbdrive vfat defaults,users,nofail,noatime,nodiratime,umask=000 0 0

I created the folder /mnt/usbdrive then, chmod 777 /mnt/usbdrive. Tried various USB cables to attach the external drive to RPi USB2 ports. Nothing allows me to see the contents of the external USB drive. When the drive is plugged into my Hackintosh USB port the entire 220gB MP3 files content of the drive is visible and can be R/W.

A simple USB memory stick formatted FAT32, not an SSD drive, does not work either attached to any of the RPi USB ports. Used the „mount“ command thru VNC and terminal after Max2Play finished booting.

When I made a mistake removing fstab option: „nofail“ the Max2Play RPi-3b would not boot. Had to edit the /etc/fstab file by connecting the Max2Play SDcard to my Synology NAS (linux-OS of course), editing the /etc/fstab file to add „nofail“ and was able to boot the Max2Play once again. I mention this because when I was able to boot into RPi „emergency mode“ no USB keyboard I tried was recognized by the RPi … none. Had to abandon „emergency mode“ since not able to use keyboard input.

Makes me wonder if the Max2Play-OS later in the bootup process has disabled all the USB ports for passing traffic. Early in the boot process the USB ports are active, which is why the OS can see my external drive status info, but later in the boot process the USB ports will not pass traffic across the bus ???? Has this symptom been seen by Max2Play ? I thought there used to be a Max2Play GUI option setting which disabled the USB ports for keyboards and mice if the system was run „headless“ ?

Thank you for reading this long post. I have enjoyed Max2Play-OS for serving music with Squeezebox Server and recommended the product to many friends. However, if I can no longer use an external USB drive with the system, I may have to use an old laptop to run Squeezebox Server (LMS). At least it can mount an external drive or load my music library into internal storage.

Many regards,

— mark early (Seattle, NW corner of Vereinigte Staaten)

UPDATE: Recognizing USB drives seems to be a timing issue. When I leave a simple USB-flash drive formatted FAT32 plugged into a USB port then power-on bootup Max2Play-OS the USB drive’s UUID is displayed correctly by command „sudo blkid“, but it’s contents are not visible either from a manual „mount“ command or from an entry in fstab. However, when the USB-flash-drive is left unplugged… bootup Max2Play-OS …. wait…plug in USB-flash-drive and then manually mount with command „sudo mount /dev/sda1 /mnt/usbstick -o umask=000“ the contents of the usb-flash-drive are correctly visible. This is obviously very inconvenient. Is there a linux/Max2Play-OS configuration setting that will fix this timing issue ?

Thank-you

UPDATE – FINAL

For the benefit of other Max2Play users who experience this external USB drive issue.
On my RPi-3b LMS music server running v2.56 of Max2Play, the contents of a FAT32 external USB-SSD drive was ultimately made available on bootup only by using the following line in /etc/fstab „/dev/sda1 /mnt/usbstick vfat defaults,users,nofail,noatime,nodiratime,umask=000 0 0“. Of course substitute your own mount point (/mnt/usbstick) and mounting options. The important point is I could not use UUID to identify the device and had to use „/dev/sda1“ instead. Even though the UUID for my external USB drive was correct it never worked for me. Also added two instructions in file /etc/rc.local just ahead of the „exit 0“ line:
sleep 20
sudo mount -a

These two instructions added to /etc/rc.local was recommended online by users who also experienced problems mounting USB drives at bootup on RPi systems.

@MarioM,

Thank you for your response. I will do more troubleshooting and respond on this thread regarding whether the desired message on Filesystem/Mount plugin (GUI tab) indicating that the HD has not yet mounted and whether using the [checkbox] for mounting results in a permanent mount of the drive after reboot… etc.

I did update the kernel when attempting to use exFAT as my external USB drive filesystem. When this still did not allow exFAT to be accessible I tried various apt-get commands to load modules that would help my instance of Max2Play use exFAT. This did not work either, so I concentrated on getting my USB drive to be seen using the FAT32 (vfat) filesystem and it’s internal driver(?). This was marginally successful as described in an earlier post with fstab entry using device source „/dev/sda1“ not UUID.

Squeezelite not starting – HiFi-Berry Amp2 No Longer Connected
Sadly, now my HiFi-Berry-Amp2 is not working as a target of SqueezeLite. Max2Play’s [Audio-Player] plugin reports Squeezelite is not running and I have not been able (and do not have enough experience) to cause Squeezelite to start at all. So my RPi-3b music player can only send music thru the local network to Google-Chromecast remote speakers. The HiFi-Berry-Amp2 is just consuming watts but not generating any sound.

*** FRAGILE SDcards OS Execution Memory Suspected ***
My guess is my RPi running Max2Play which has performed well for many years (though with limited use), has become fragile as it seems too many RPi systems are prone to. Could be the weakness of relying on an SDcard to execute the OS, which these memory cards were not designed by the manufacturers to do sustainably. I have read this is a hardware problem with almost all RPi systems running from SDcards and not the fault of an OS like Max2Play.

*** Reloading the Max2Play image onto New SDcard – Preserving old Settings ? ***
My question for the Max2Play forum: What is the best procedure to follow, to start from scratch and reload the Max2Play OS onto a new SDcard from the Max2Play install image, yet retain most of my settings and configuration without having to manually re-establish each and every configuration setting ?

Until the Raspberry Pi community can transition from unreliable SDcard memory to a proper host memory hardware design that executes code from memory intended for repeated OS code execution, applications that use RPi SDcard based hardware, like Max2Play will be unfairly blamed for unreliable performance, when as an electronics person I think a good deal of the issue originated with hardware choices years ago necessitated by low cost requirements: SDcards. There are reliable memory choices today at a slight cost increase which would allow code to run faster and remain reliable. Until better memory is used, I and many other Max2Play users are stuck reloading the OS image onto new SDcards (or some other execution memory) as the applications we enjoy using become flaky due to OS code and config file corruption.

Sorry for the delayed reply and update.

Very good advice from MarioM to: „…burn a fresh Max2Play image setting up everything from scratch…“ which is mostly what I did.

This worked to restore both the audio output to my analog speakers from my HifiBerry Amp2 hat and also allowed my Rpi-3b to see and mount an external USB-drive with it’s vFAT filesystem containing my local library of MP3 music files. Previously the external USB-drive filesystem was EXT4, which is certainly a better filesystem than vFAT (exFAT ?) but I wanted the ability to unplug the USB-drive from the Max2Play server and update the library from another computer if necessary. Also setup a SAMBA share on the Max2Play and will see if I can update the library remotely over the LAN just as I had before my Max2Play system became damaged, most likely from my own error in updating and reconfiguring the OS.

I appreciate the advice and support from Max2Play and will most certainly renew my Max2Play license again when it comes due.

Was able to restore Max2play settings I had previously documented. When I re-installed Squeezebox-Server (LMS) to the latest v8.3 build (my previous version was v8.2) everything worked just fine, however I made the mistake of reloading a 500-MB backup xx.tar file of old LMS settings. Thought this would mostly be LMS plugins and a few config files, but it seems to have also contained my old library database which pointed to the wrong music library location. Should have known the plugins and config files were not likely to be 500-MB in size, though a full database could be. Have pointed LMS to the new correct music library on the USB-drive and LMS is deleting the old database entries, re-scanning and hopefully will patch the new database ..etc. Mentioning this so other users will avoid my mistake if pointers to their music library have changed since the LMS settings backup was saved.

Thank-you, from the NW corner of the Vereinigte Staaten.