I am using a Pi4 based volumio with Waveshare 7" display.
Charger used is a 5V 3A charger from Realme.
I have a 2.5" 1TB HDD connected with FLAC files. It works fine, but after several hours usually overnight it gets disconnected and then it never gets connected back. Music library would be shown as Empty. I would have to restart volumio once it happens, for the hdd and its files to appear again.
Please let me know if any other details needed. Any help with this?
Hey @njaustin123,
To investigate this I need the full picture of the setup. Right now there is not enough to work with.
Please provide the following.
Exact Raspberry Pi 4 revision code. Use this guide:
The exact version number, for example 3.756 or 4.143. Not “latest”.
DAC, dongles, HATs, fans, keyboard, anything on USB or GPIO. All of it, including the boot media type (SD card, USB stick, SSD).
This is the important one, and the timing matters.
When the drive has gone and the library shows Empty, do NOT reboot. In that failed state, open http://<your_volumio_IP>/dev in a browser, send the log, and paste the URL here.
Reference
https://help.volumio.com/help/how-to-send-a-log-link-for-a-bug-report
A log taken after a restart is of no use. The drive is back by then and the kernel messages covering the disconnect are gone. I need the log from the morning, before you touch anything.
One further note on the power supply. A 5V 3A phone charger is not a Raspberry Pi 4 supply and I will want to know its exact model, but I am not drawing any conclusion from that until I have seen the log.
Kind Regards,
This morning the issue wasn’t reproduced. WIll get back with log once that happens.
Below the other details:
Got the issue again and this is the log:
http://logs.volumio.org/volumio/2ETlu1l.html
On the charger, it is a mobile charger from realme (same as Oneplus, Oppo brands) which is 5V 3A in non-fast charging mode. Thier fast charging is proprietary.
Hey @njaustin123,
Thank you for the board revision, version and the log. I have gone through it.
What the log shows around the disk- the failure in this log happened at 13:28 on 28 August, not overnight. Sequence:
13:28:06 ntfs-3g[1498]: Unmounting /dev/sda1 ()
13:28:06 systemd: media-3A0028380027FA11.mount: Deactivated successfully
13:28:11 Volumio: Mounting Device 3A0028380027FA11
13:28:12 ntfs-3g[17659]: Mounted /dev/sda1 (Read-Write, NTFS 3.1)
13:28:12 ntfs-3g[17659]: Unmounting /dev/sda1 ()
After that, every access to the disk fails and MPD removes the library, which is why it shows as empty. At the time the log was taken, nearly three hours later, the drive was still present on the USB bus and still enumerated normally, but the mount point was dead:
df: /media/3A0028380027FA11: Transport endpoint is not connected
So the drive itself did not vanish from the system. The filesystem mount did.
At the same second the mount went away, the Volumio backend restarted after a crash coming from the YouTube Music plugin. That means I currently have two possible explanations sitting on top of each other and no way to separate them:
Until that second variable is removed, any conclusion would be guesswork.
What I need you to do
Step 1 - remove the backend crash from the picture
Go to Plugins, Installed Plugins, and disable YouTube Music. If you do not use it at all, uninstall it. If you also do not use YouTube Cast Receiver, disable that too. Then reboot once so we start from a clean state.
Step 2 - wait for the disk to drop again
When it happens, do NOT reboot and do NOT unplug anything. In that failed state, connect by SSH and run these two commands, then paste the output here:
sudo dmesg -T | tail -n 200
mount | grep sda
Then, still without rebooting, send a fresh log from:
http://<your_volumio_IP>/dev
and paste the link here.
The dmesg output is the important part. Your current log contains no kernel messages at all, and the kernel is the only thing that can tell us whether the drive, the USB bridge or the link actually failed. A log taken after a reboot is of no use, because the drive is back by then and the evidence is gone.
If the plugin is disabled and the disk still drops, we know the backend is not involved and we are looking at the drive, the enclosure or the USB link. If it stops dropping, that tells us something too.
Kind Regards,
@nerd , Thanks a lot for the detailed investigation and instructions. I have disabled YT Music and YT Cast plugins. Restarted Pi and rebuilt the music library from HDD. Will keep it observed and report back.
@nerd , checked it back after an inactivity of about 12 hours overnight. Still worked.
Will check and report back tomorrow.
@nerd , checked again this morning after another 12-14 hours of not using it. Still not disconnected and working. So issue with YT Music - what do you think?
Hey @njaustin123,
Thanks for testing over two nights - that is useful.
I would not close it on YouTube Music yet. Working theory, based on your log and the Volumio source:
The drive never actually disconnected. It stayed on the USB bus the whole time. What died was the mount. It looks like the filesystem handler is running inside the same service group as the Volumio backend, so when the backend restarts for any reason, the handler is killed with it and the mount is left dead. That fits your log and it fits the fact that only a reboot brings the disk back.
If that is right, the plugin was only the thing that happened to crash the backend on your unit. Any backend restart would do the same.
One test to confirm it, takes a minute. With the disk mounted and working, over SSH:
mount | grep /media
sudo systemctl restart volumio
sleep 30
mount | grep /media
ls /mnt/USB/3A0028380027FA11
Paste all of the output here.
If the disk is gone or unreadable after that restart, the theory holds and this is a platform issue on our side, not a fault with your drive, cable or power supply. If the disk survives the restart, the theory is wrong and I go back to the log.
Kind Regards,
It did not survive the restart, media turned empty. Please see below:
/dev/sda1 on /media/3A0028380027FA11 type fuseblk (rw,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sda1 on /media/3A0028380027FA11 type fuseblk (rw,noatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
ls: cannot access '/mnt/USB/3A0028380027FA11': Transport endpoint is not connected
Hey @njaustin123,
That is exactly what I needed. Thank you.
You have reproduced it on demand, with no plugin involved. A plain restart of the Volumio backend kills the mount:
before: /dev/sda1 on /media/3A0028380027FA11 type fuseblk (rw,noatime,...)
after: /dev/sda1 on /media/3A0028380027FA11 type fuseblk (rw,noatime,...)
ls: Transport endpoint is not connected
The mount entry is still there, but the filesystem handler behind it is dead. Same end state as the failure in your log. So the disk, the cable, the enclosure and your power supply are all cleared. Your drive never disconnected at any point - it stayed on the USB bus throughout.
YouTube Music was only the thing that happened to crash the backend on your unit. Any backend restart does the same, from any cause.
One more command, and this is the last one I need. Run it while the disk is working, before restarting anything:
systemctl status volumio | head -20
cat /proc/$(pgrep -x ntfs-3g | head -1)/cgroup
Paste the output. That tells me whether the filesystem handler is being started inside the backend’s own service group, which is what I currently believe is happening. If it is, the whole thing is explained and I can take it to the developers with a reproducer.
In the meantime, you do not need to reboot when this happens. This should bring the disk back on its own, though I have not tested it on your setup:
sudo umount -l /media/3A0028380027FA11
sudo systemctl restart volumio
Keep the YouTube plugins disabled for now. That removes the thing that was restarting your backend, which is why the last few nights have been clean.
Kind Regards,
sudo umount -l /media/3A0028380027FA11
sudo systemctl restart volumio
Thank you. Doing the above plus clicking “Update” from Sources make it back alright.
And here is the output of
systemctl status volumio | head -20
cat /proc/$(pgrep -x ntfs-3g | head -1)/cgroup
● volumio.service - Volumio Backend Module
Loaded: loaded (/lib/systemd/system/volumio.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/volumio.service.d
└─override.conf
Active: active (running) since Sun 2026-08-30 13:27:46 IST; 5min ago
Main PID: 23017 (node)
Tasks: 63 (limit: 1837)
CPU: 1min 8.355s
CGroup: /system.slice/volumio.service
├─23017 /usr/bin/node /volumio/index.js
├─23049 /bin/bash /volumio/app/plugins/system_controller/network/network_monitor.sh
├─23086 /sbin/mount.ntfs /dev/sda1 /media/3A0028380027FA11 -o rw,noatime,dmask=0000,fmask=0000,iocharset=utf8
├─23094 /usr/bin/node /volumio/app/plugins/miscellanea/albumart/serverStartup.js 3001 /data/albumart
├─23104 /usr/bin/node /volumio/app/plugins/miscellanea/albumart/serverStartup.js 3001 /data/albumart
├─23105 /usr/bin/node /volumio/app/plugins/miscellanea/albumart/serverStartup.js 3001 /data/albumart
├─23106 /usr/bin/node /volumio/app/plugins/miscellanea/albumart/serverStartup.js 3001 /data/albumart
└─23807 sleep 10
Aug 30 13:30:33 austreamer volumio[23017]: info: CoreCommandRouter::executeOnPlugin: mpd , getMyCollectionStats
Aug 30 13:30:37 austreamer volumio[23017]: info: CoreCommandRouter::executeOnPlugin: mpd , getMyCollectionStats
cat: /proc//cgroup: No such file or directory
Is there any error in the command or the way I executed? (cat: /proc//cgroup: No such file or directory)
Hey @njaustin123,
Your command was fine. The process is named mount.ntfs rather than ntfs-3g, so pgrep found nothing and the path came out as /proc//cgroup. No need to run it again, because the answer was already in the first half of your output:
CGroup: /system.slice/volumio.service
|-23017 /usr/bin/node /volumio/index.js
|-23086 /sbin/mount.ntfs /dev/sda1 /media/3A0028380027FA11 -o rw,noatime,...
The filesystem handler for your disk is running inside the Volumio backend’s own service group. When the backend stops or restarts, that handler is killed with it. The mount entry stays in the table, but nothing is behind it any more, which is the “Transport endpoint is not connected” you saw. The backend then remounts on startup without clearing the dead entry, so the disk stays unusable until a reboot or the manual unmount you ran.
Your drive, cable, enclosure and power supply are all cleared. The disk never disconnected at any point.
I have filed it:
Your reproduction and the cgroup output are both in there. Thank you for running the tests properly and for not rebooting before capturing the log - that is what made this findable.
For now:
sudo umount -l /media/3A0028380027FA11
sudo systemctl restart volumio
Then hit Update in Sources, as you already worked out.
I will update this thread when there is a fix.
Kind Regards,
Thanks a lot @nerd . Happy to be part of this debugging.
I will wait for the fix.
BTW, I believe this should be a common problem faced by many. I wonder why it is not already logged by anybode else.
I believe that I used to encounter issues with Volumio and locally-attached USB drives many years ago. I resolved this problem by relocating my FLAC library to a separate NAS device or server on my local network, and pointing the Volumio library to my network share instead. I imagine that this is what most people do and likely why the problem is not reported more frequently.
You are probabbly right.
Hey @njaustin123,
The drive never left the USB bus. A backend crash or restart killed mount.ntfs because it was started as a child of the Volumio process. The mount point stayed in the table but was dead (ENOTCONN). MPD then treated that as “USB gone” and emptied a library it already had.
That is a platform bug. Your disk, cable, enclosure and PSU are not in question.
Fix is up for review. Both parts have to land together:
I did my part, rest is with @volumio
Kind Regards,
Thank you again, @nerd . Appreciate the quick response and fix. Now I need to wait for volumio team to release this fix in one of the upcoming releases, I believe.