Closed Vandino86 closed 4 years ago
The first suspicion that comes to mind is general incompatibility of some USB drives. Are you able to manually mount the drive using instructors mentioned here?
Another thing to consider is whether the power supply is able to provide enough voltage for the USB drive and the pi. This post provides a few ways to diagnose if your pi is operating under low voltage.
The first suspicion that comes to mind is general incompatibility of some USB drives. Are you able to manually mount the drive using instructors mentioned here?
Another thing to consider is whether the power supply is able to provide enough voltage for the USB drive and the pi. This post provides a few ways to diagnose if your pi is operating under low voltage.
I am using a 2.5 amp power supply, so I don't think that power delivery is an issue here. I am able to manually mount the drive and share it's contents through SMB. Pretty sure that the problem is that the drive isn't being automatically mounted on boot for whatever reason. Therefore, it falls back to the share directory on the microSD card. I don't want to have to configure this manually through SSH every time I turn on the Pi. I tried this method for mounting the flash drive permanently, but it broke the installation and I had to re-write the image to the card to get it working again.
Since the issue is specific to the drive you are using, it's a bit difficult to diagnose on the other side. The mechanism for auto-mounting USB drives is contained here, it may be possible to modify this to work with your device. Does the drive auto-mount if you hot-plug it after booting? Have you tried using a different USB drive to see if the issue still exists?
I tried a 32 GB Kingston USB 2.0 flash drive, and if I remember correctly, the Pi was actually able to mount it to a directory, but the SMB share was still set to the directory on the microSD card instead. Hot-plugging didn't seem to work with the 64 GB flash drive when I first tried doing that, but I'll try doing it again when I get home, but this time, I'll try to look closer at what's going on in the SSH terminal. I'll also try hot-plugging with the 32 GB drive.
It should also be noted that a year or two ago, I tried using my same Pi with the same 64 GB drive (formatted to NTFS) to play games through Ethernet on my slim PS2 with OPL by installing and configuring OpenMediaVault on my Pi according to this tutorial, and it actually worked. I was able to view, boot, and play games off the flash drive on my Pi wired to my PS2 through Ethernet. So this might be an issue with how psx-pi-smdshare handles certain flash drives compared to OpenMediaVault.
I've verified with a generic USB stick and latest image release that the auto-mounting / sharing feature is working as intended on my end, but am curious as to why this would not work with either of your Kingston flash drives.
First a brief overview of how automount-usb.sh works:
The automount-usb.sh
script is ran one time during execution of setup.sh. After this initial run, it will install ntfs-3g for NTFS filesystem support in addition to pmount for USB hot plug support. After this, two systemd rules are created which direct the OS to run a handler script when a USB disk is inserted and removed from the USB port. On insertion, a script located at usr/local/bin/automount.sh
will execute, essentially this script will perform the initial mounting of the drive via pmount, then recreate the samba share to point to this new mount point. When a drive is removed, it will trigger the execution of /usr/local/bin/samba-init.sh
, this has an effect of defaulting back to sharing from the internal SD card.
Now we can look at ways to diagnose these mechanism with your USB drives:
When you plug in your USB drive, it should be mounted to a path at /media/sd*1
(The value of will depend on the character assigned to the drive by the OS). You can verify this by listing directory contents of `/media/sd1. If you see this, it confirms that the drive was successfully mounted by the systemd insertion handler via pmount. If this fails, we need to look at why pmount is failing to mount the drive, the command in question would be the following: [
runuser pi -s /bin/bash -c "/usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}"`](https://github.com/toolboc/psx-pi-smbshare/blob/master/automount-usb.sh#L70). Where ${PART} is the name of the drive as it exists in /dev i.e. sd*1.
If the mounting of the drive is successful, but you still do not see the drive over SMB, then we need to look at the recreated samba share point. The recreated share point will still be served over SMB at a path named share
but instead of mounting from the SD card path, it will mount using the path that was created by pmount when the drive was inserted. To diagnose this, take a look at /etc/samba/smb.conf
after plugging in the USB drive and verify that Path = /media/$PART
. Where $PART is the name of the drive as it exists in /dev i.e. sd*1.
If you have verified both of these mechanisms to be successful, you should be able to see the contents of your USB drive are now served at the SMB path //SMBSHARE/share
.
While testing, I did notice that USB drives do not automatically get shared on boot. This is because a crontab entry is created which essentially falls back to sharing the SD on boot. Ideally, if a USB drive is plugged in on boot, we should share the USB drive and not the SD. This has been addressed in https://github.com/toolboc/psx-pi-smbshare/commit/d49fda3c49218a3a364cdeaa7222337dc1808701. I have published an updated release containing this fix.
I updated my psx-pi-smbshare installation. My 32 GB Kingston USB 2.0 flash drive now gets automatically mounted and shared every time it gets plugged in. My 64 GB PNY USB 3.0 flash drive, however, doesn't. I have to mount the 64 GB drive to (for example) /media/usb
manually, then set that as the value of the Path
variable in /etc/samba/smb.conf
manually, and finally restart Samba (sudo service smbd restart
) to get it to share the contents of the drive.
I'm not sure why my 64 GB drive isn't being mounted automatically, and I'm not sure how I can troubleshoot this. Should I just straight up run the command runuser pi -s /bin/bash -c "/usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}"
with the 64 GB drive plugged in and see what happens?
Below are the outputs of different disk info-related commands for both my flash drives. Hopefully, these will be useful for debugging. Thanks.
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdf 8:80 1 28.9G 0 disk
└─sdf1 8:81 1 28.9G 0 part /media/sdf1
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 43.1M 0 part /boot
└─mmcblk0p2 179:2 0 14.8G 0 part /
sudo blkid
/dev/mmcblk0p1: LABEL="boot" UUID="A365-6756" TYPE="vfat" PARTUUID="282a0537-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="90a83158-560d-48ee-9de9-40c51d93c287" TYPE="ext4" PARTUUID="282a0537-02"
/dev/mmcblk0: PTUUID="282a0537" PTTYPE="dos"
/dev/sdf1: LABEL="NEW VOLUME" UUID="4631-D11F" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="2d2538b1-a216-4eaa-bac6-904ea3fe0371"
sudo fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x282a0537
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 96453 88262 43.1M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 31116287 31017984 14.8G 83 Linux
Disk /dev/sdf: 28.9 GiB, 31001149440 bytes, 60549120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6537B96A-5706-4153-BCA0-00FED9036840
Device Start End Sectors Size Type
/dev/sdf1 2048 60547071 60545024 28.9G Microsoft basic data
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdg 8:96 1 59.1G 0 disk
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 43.1M 0 part /boot
└─mmcblk0p2 179:2 0 14.8G 0 part /
sudo blkid
/dev/mmcblk0p1: LABEL="boot" UUID="A365-6756" TYPE="vfat" PARTUUID="282a0537-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="90a83158-560d-48ee-9de9-40c51d93c287" TYPE="ext4" PARTUUID="282a0537-02"
/dev/mmcblk0: PTUUID="282a0537" PTTYPE="dos"
/dev/sdg: LABEL="PS2 PI" UUID="A663-F44E" TYPE="exfat"
sudo fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mmcblk0: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x282a0537
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 96453 88262 43.1M c W95 FAT32 (LBA)
/dev/mmcblk0p2 98304 31116287 31017984 14.8G 83 Linux
Disk /dev/sdg: 59.1 GiB, 63484985344 bytes, 123994112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdg1 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdg2 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdg3 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdg4 4294967295 6854241533 2559274239 1.2T ff BBT
@Plut0nio,
I'm glad to hear the 32GB disk is working!
Thanks a ton for providing detailed debug info, at first glance I noticed that when looking at the output of fdisk -l
for the 32GB and 64GB disks, that something looks off.
The 32GB disk is recognized as gpt with a vfat filesystem and a single partition at (/dev/sdf1)
Disk /dev/sdf: 28.9 GiB, 31001149440 bytes, 60549120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6537B96A-5706-4153-BCA0-00FED9036840
Device Start End Sectors Size Type
/dev/sdf1 2048 60547071 60545024 28.9G Microsoft basic data
The 64GB disk is recognized as dos (MBR) with a BBT filesystem and four partitions at (/dev/sdg1, /dev/sdg2, /dev/sdg3, and /dev/sdg4 ) with enormous sizes (2T!?)
Disk /dev/sdg: 59.1 GiB, 63484985344 bytes, 123994112 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdg1 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdg2 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdg3 4294967295 8589934589 4294967295 2T ff BBT
/dev/sdg4 4294967295 6854241533 2559274239 1.2T ff BBT
This makes me wonder if this drive would report the same result with a stock Raspbian image.
Does the 64 GB disk also fail to mount when formatted with a gpt partition table? For more information on the difference between GPT and MBR see: https://www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive
This could also be an issue with pmount. What happens when you run the following (Assuming the 64GB drive is mapped to /dev/sdg*)?
runuser pi -s /bin/bash -c "/usr/bin/pmount --umask 000 --noatime -w --sync /dev/sdg1 /media/sdg1"
After running this command, navigate to /media/sdg1 to check if the drive mounted appropriately. If this command fails, it should provide output that will give a clue as to the root cause of failure.
Shortly after I posted my disk command outputs, I decided to reformat my 64 GB drive from MBR exFAT to GPT exFAT (my 32 GB drive was already GPT, so I left that drive alone) to see if it that would make it work. And lo and behold, my 64 GB drive was finally automatically mounted and shared by the Pi! Thank you very much for the help. I might try fooling around with an MBR-formatted flash drive and seeing what happens if I try to mount it with that runuser
command, but I'm just glad that this finally works.
Huge congrats! Thanks for working with me together on this, no doubt others will find this info useful and major props on uncovering the issue of automount not working on boot.
Glad everything is working, going to close the issue. Feel free to reopen the issue if tests prove anything of interest.
Very curious what was the root cause for this particular issue. I happen to use a 8gb usb 2.0 corsair flash drive and my raspberry pi never had an issue detecting it for my ps2 games during testing. It is FAT32 and MBR partition style.
Very glad this issue got fixed, as I recommended to op to make a github ticket. :)
Thanks for suggesting the idea to OP to create the issue @VersatileNinja. This project aims to be user-friendly + issue-free and you’ve been a great contributor to the cause.
If I had to guess, the root cause is either some odd combination of MBR with an unsupported filesystem OR a temporarily corrupted drive given the weird output from ‘lsusb-l’.
I'm trying to get this software to work properly with my Pi 3 Model B+ and a PNY 64 GB USB 3.0 flash drive so I can play games off the flash drive using OPL (ver. 1815) on my slim PS2. However, for whatever reason, the flash drive doesn't appear to get mounted. I found this out after browsing the share folder through SMB and then browsing the same folder directly on the Pi's microSD card plugged into my laptop. In both those cases, the DVD and CD folders were empty while the ART folder contained files for Tobal 2 and X - Unmei No Sentaku. On my flash drive, the DVD and CD folders contain 20 ISOs and 1 ISO respectively, while the ART folder contains the art for all those games. My Pi detects the flash drive as a USB device, as
lsusb
returnsBus 001 Device 006: ID 154b:00d2 PNY
, but for some reason, the microSD card's share folder is shared instead. Why is this happening? I've tried all 3 formats compatible with Windows so far for my flash drive: FAT32, NTFS, and exFAT. Thanks.