Cannot Unmount

  • I have a Raspberry Pi with a 1Tb attached HDD which is used for PC backup and as a music server. I am unable to unmount it in OMV as the umount button is grey. When I try umount in PuTTY it tells me:


    root@raspberrypi:~# umount /dev/sda1umount: /media/22f45667-e682-4224-9f5e-818e3762e0db: device is busy.


    This is odd as:

    • the HDD is data only
    • I only have one program installed (Logitech Music Server) and this is inactive. If I stop the service and I still get the same "device is busy" in PuTTY
    • I back-up from the PC to the HDD using FreeFileSync (i.e. I push to the HDD) and this is not running

    Looking around for commands that my help me understand what is happening I tried:


    root@raspberrypi:~# fuser -v ./USER PID ACCESS COMMAND/root: root 27036 ..c.. bash


    Any idea what I need to do, please?




    OMV 2.2.5
    Raspberry Pi 3 model B
    Logitech Media Server 7.9

    OMV 4.1.8.2-1
    Rock64, 1Gb
    Logitech Media Server 7.9.2

  • I don't understand what shared folders/services might be using the HDD. It is only a data disc that is only looked at by me backing up my PC and by my media server when it is playing music stored on the HDD.


    I stopped the media server in PuTTY and I am not backing-up to the drive. From my perspective it should be dormant.


    Can you advise what I need to do now?

  • Thanks for the answer.


    Yes, I had Shares enabled. Disabling Services/SMB/CIFS/Shares (and then accepting this change) still has the HDD referenced in File Systems.


    Likewise, disabling Services/SMB/CIFS/Settings/General settings still has the HDD referenced in File Systems.


    Is there a way to find out what is referencing the HDD so that I can unmount it?

    OMV 4.1.8.2-1
    Rock64, 1Gb
    Logitech Media Server 7.9.2

  • Resurrecting. I too have shares defined, but I've disabled the shares and stopped the service, yet the filesystem still shows as being referenced. Surely I don't have to DELETE the shares just so I can unmount the volume!





  • Wow! Guess I'll just do it manually at the command line (which I ended up doing - needed to resize the filesystem). That sure seems like a long way to go to do any drive maintenance.


    Wouldn't it be better for the interface to recognize whether there are actual files in use on the volume to determine whether to allow mount/unmount?

    • Offizieller Beitrag

    Wow! Guess I'll just do it manually at the command line (which I ended up doing - needed to resize the filesystem). That sure seems like a long way to go to do any drive maintenance.


    Wouldn't it be better for the interface to recognize whether there are actual files in use on the volume to determine whether to allow mount/unmount?

    Is not that simple. A unmount command unregisters the disk from the db. If this was forced without deleting the shared folders it would make the internal id unavailable for the shared folders to refer to. This renders in all sort of db errors in the web ui.
    It has been like this since the beginning, it would need a db change, which I guess is not that simple.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!