I'm trying to debug something that I don't quite understand well.

I have setup an automount of an external drive with:

/etc/fstab UUID={RANDOM_UUID} /media/pi/Storage ext4 defaults,nofail,x-systemd.device-timeout=10s 0 0

I also have setup a docker image with a volume pointing to that drive, and the container saves some files there. But then the drive gets unmounted somehow and the docker container keeps writing but to the Raspberry Pi Storage.

With vcgencmd get_throttled I was able to see that I sometimes get undervoltage and that could be the main problem. I tried to setup an script that detects undervoltage and restart the Raspi, but this looks like not the proper solution.

Is there a native way of knowing when the unmount happens and stop the docker image from writting onto the Raspi storage?

3 Answers 3


Your problem has several suspects, but your question has not provided enough information to eliminate any of them. Here are some ideas:

1. Your /etc/fstab option: x-systemd.device-timeout=10s

Why do you leave this in when you're trying to troubleshoot mount issues?

2. As suggested by both of the other answers: You should put some code in your docker container to test for the presence of the mount before attempting a write.

I'd suggest you take a look at findmnt to perform this test. Another tutorial reference on findmnt is found at HTG.

3. Awareness of the under-voltage condition

An interrupt would be the best way to get useful information on under-voltage events. But AFAIK, there is no way for us mortals to get an interrupt from the RPi (if it even exists) with stock hardware & closed-source firmware. There have been a few discussion threads at the sawmill on that - for example, but I'm not aware of anything useful. Without an interrupt, we are stuck with polling - as suggested in @goldilocks' answer - and its attendant lower time resolution.

But don't get discouraged by inadequate event time resolution. If you're getting regular reports of low voltage from the vcgencmd get_throttled reports, this is something you should address. In other words:

  • Get a better power supply
  • Use the shortest power leads possible
  • Use the heaviest AWG wiring available in your power leads

Other, fyi:

If you're interested in the "mechanics" of the Low-Voltage warning, there are some details in this answer that may be of interest. There's enough information here to enable you to do a real-time capture of a low-voltage event using a simple voltage comparator (e.g. to generate an interrupt) - or with an oscilloscope. But again, I don't recommend that if vcgencmd get_throttled has informed you that these low voltage events are happening as you've already got the evidence you need to pursue a remedy to your power supply issues.

  • Thank you for this in deep answer of what my options are! Option 1 was because I read somewhere that if it fails it could take up to 90 seconds to boot. Option 2, I can't think of a way of doing that since I am pulling an image from somewhere else. I could potentially extend that image with that check, so I'll keep this option if I can't solve the undervoltage. Option 3 I think is the way to go here, I'll plug the Raspi directly to a power source instead of relying on the USB hub (It has a source output, but It might not be ideal) Sep 19, 2022 at 22:32
  • @GermanCasares: That sounds like the best place to start as RPi is very finicky about power. Not sure I'm clear on your response to Option 2 (test for mount ??), but if your program depends on a valid mount point, it's always a good idea to verify it early in your code sequence.
    – Seamus
    Sep 19, 2022 at 22:56

Docker is a red herring here.

If you have code that writes to mounted storage YOU need to ensure that the storage is ACTUALLY mounted. Otherwise you will write to the mount point with undesirable consequences. I include such a test in my code.

The other issue you mention is a different problem. If mounted devices unmount it is usually a power related issue. Pi USB ports have limited current capacity - use of powered drives or hubs may help.


That the writing continues once the mount is gone implies that it may be opening a file and writing as opposed to holding it open (although that's probably still not impossible). You should check the mount point when nothing is on it to see if any data has been left in that directory (although this doesn't matter much unless you want that data, or it is of sufficient volume to take up too much space on the SD card).

Is there a native way of knowing when the unmount happens and stop the docker image from writing onto the Raspi storage?

The ideal way to do this would be with udev or inotify but there is not much in normalising the scenario -- as Milliways points out, it is likely a power issue, but in any case it is something you need to remedy.

In the meantime here's something simple that could be run at intervals, presuming the mount point is /mnt/mydrive:


mount | grep "/mnt/mydrive"
if [ $? -ne 0 ]; then
    # Whatever you want to do here if the mount is gone.
    sleep 30s

The sleep 30s bit is a way of keeping this running at intervals, either run this in the foreground of a terminal or background it (./myscript &) and don't log out. Alternately you could run it via cron or whatever such mechanism you are comfortable with.

  • I agree with your solution of a bash script & running it with Cron jobs. I initially though of doing that, but detecting an undervoltage and doing a restart on the Raspi. Sep 19, 2022 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.