Max2Play Home 2016 (en) › Forums › Max2Play on Raspberry PI › External USB drive Formatted exfat plugged into Raspberry Pi 3b NOT mounting
This topic contains 7 replies, has 2 voices, and was last updated by Mark-in-Seattle_GMT8 premium 5 months, 2 weeks ago.
Posted in: Max2Play on Raspberry PI
30. August 2022 at 15:25 #52371
Tried repeatedly without success to mount an external USB SSD drive formatted with exfat filesystem into Raspberry Pi 3b USB port #0 running the latest stable Max2Play OS with updates. The external usb drive contains my music library folders of MP3 files, yet no folders or files are visible to the Max2Play Raspberry Pi using VNC session into the RPi-3b.
Max2Play [Filesystem Mount] tab, generated the following information fields when USB drive is plugged in:
UUID=6130-0BC2 /mnt/extdrive exfat defaults,nofail,noatime,discard,iocharset=utf8
„ExFAT-SSD in not mounted (Device /dev/sda2 with UUID 6130-0BC2)“
However the folder /dev/disk/by-uuid/ contains several link files the longest one of which is named: 28590797-4810-4851-b4ec-bf9672c2918c which sure looks like a proper UUID to me, though I do not know what is the proper UUID form for an „exfat“ formatted drive.
/etc/fstab usermount section is as follows, as viewed from VNC session running nano editor:
UUID=6130-0BC2 /mnt/extdrive exfat defaults,nofail,noatime,discard,iocharset=utf8 0 0
Tried the using the longer UUID=28590797-4810-4851-b4ec-bf9672c2918c value but still my known to be working external USB drive is not visible to Max2Play OS. Also tried using fstab line with „vfat“ substituted for „exfat“ as the filesystem type. Not familiar with the fstab option „iocharset=utf8“. Previously used „apt install exfat-fuse“ and „apt install exfat-utils“ commands logged in as root to provide Max2Play OS with exfat drivers as described in an online Raspberry Pi article.
At my wits end and still my known to be working external USB drive is NOT visible to Max2Play OS.
Any suggestions about what I could try next to mount the external USB drive ?
Thank you.31. August 2022 at 10:13 #52375
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.
1. September 2022 at 13:09 #52379
- This reply was modified 6 months, 3 weeks ago by Mark-in-Seattle_GMT8.
Normally, exfat formatted storages should be recognised automatically by the system. When they are recognised they should be mountable via the filesystem/mount plugin.
If you need FUSE to make the Pi exfat compatible, you could try the following two commands:
sudo apt-get install exfat-fuse sudo apt-get install exfat-utils
However, this has not been tested by us. We can therefore neither guarantee that the installation will work nor that Max2Play will still function correctly afterwards.3. September 2022 at 11:01 #52386
@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/
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
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.
— 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 ?
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:
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.6. September 2022 at 12:05 #52389
I am sorry that you had so many problems with mounting. Thank you for sharing your experience, maybe it will help other users who encounter a similar problem.
In principle, mounting with the Max2Play OS should work with all common formats, regardless of whether the hard drive was connected before or after booting. If the hard disk is recognised, a corresponding message should appear in the Filesystem/Mount Plugin indicating that the hard disk has not yet been mounted. If the checkbox for mounting the hard disk is activated and the Save button is clicked, the hard disk should be permanently mounted and show up in the mounts list at the top.
If this option is not available or mounting does not work in this way, then the Max2Play image may be damaged or a kernel update has caused the mounting to no longer work as before, so we have to make adjustments to our image (this was the case, for example, when switching from stretch to buster).7. September 2022 at 10:17 #52394
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.8. September 2022 at 14:00 #52397
I’m sorry that your image is now broken. I would recommend using a new SD card and burning a fresh Max2Play image and setting everything up from scratch. There is the possibility to backup the image and write it to a new SD card, but then you would also inherit all the errors. Unfortunately, it is not possible to save only the plugin settings.
If you do not necessarily need the latest kernel and packages, I would advise you not to update them manually, but to wait until we offer a new image with an updated kernel. With manual updates, we can never guarantee that the system will still function correctly afterwards.
If you have burned the new image onto the SD card, please check (before you make changes to the system or the plugins) whether the hard disk is recognised in the file system/mount plugin and whether you can save/mount it. I would advise you not to mount the hard disk manually via commands, but to use the functions in the Max2Play web interface. This way we can help you better with troubleshooting.9. Oktober 2022 at 12:24 #52426
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.
You must be logged in to reply to this topic.