Auto mount USB drive when reconnected

  • Hey hope this is the right area. I'm new to OpenMediaVault and was hoping someone could help me. I'm using a Raspberry Pi and a USB hard drive. I have everything set up correctly and everything works, but when I turn the external drive off and then turn it back on, the drive doesn't mount again on it's own. It mounts when I restart the Raspberry Pi or manually mount it in the Web UI, but I was wondering if there's a way I can make it automatically remount when I turn the drive back on? Thanks

    • Offizieller Beitrag

    Hey hope this is the right area. I'm new to OpenMediaVault and was hoping someone could help me. I'm using a Raspberry Pi and a USB hard drive. I have everything set up correctly and everything works, but when I turn the external drive off and then turn it back on, the drive doesn't mount again on it's own. It mounts when I restart the Raspberry Pi or manually mount it in the Web UI, but I was wondering if there's a way I can make it automatically remount when I turn the drive back on? Thanks


    This is expected behavior. The drive unmounts automatically, obviously because it gets turned off. Mounting a drive is handled by fstab... so.. as far as I know, you're either going to have to remount it in the webUI, or i *think* if you have ssh access, you can mount -a and that will remount the drive (since it should be in your fstab configuration)

  • Yup, 'mount -a' is what you're looking for to remount it easily. Otherwise you would need an udev rule specific to your usb drive.


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

  • Hi Gents & Gals(maybe?),


    one step further in Pi with OMV and probably solving the issue that pbauer and I faced - with RAID and with not mounting drive on reboot:


    I realise (now) that the USB drives are not mounting each time automatically...after a reboot. Ah ah ah!


    Which probably was a real problem for the RAID manager to access the disks....potentially...


    I had this issue of losing the USB drives after having removed the RAID so clearly not a RAID issue but a USB mount issue with fstab. (and of course my Samba was donw because of not USB disk mounted, eh eh eh!)


    So each time I had to manually 'mount -a' ... a pain in the neck... really. Browsing for a boot script around gave me the answer:


    I had to use this post here http://www.htpcguides.com/prop…usb-storage-raspberry-pi/ - scroll down to the chapter : "
    Fix Raspberry Pi 2 Mounting Issues"
    This does 2 things - add a delay on bootup and activate "mount -a" via a boot script.


    So now I have USB drives mounting properly mounted at each boot!


    I have not dared to re-configure the RAID 1...(still planning of using rsync instead).


    But if some want to use RAID on Pi they should know about this - I think. (it was new to me!).


    Hope this helps.


    Best


    rfv


    ps: Started hacking with ZX81 (yeah I know I am the Yoda of the team, I guess!)- and Raspi is to young generation what ZX81 was to mine!
    I just love it! Triple bang for the Raspi Foundation!


    pps: just to cross reference as this issue of USB not mounting leads to RAID failure, it was also discussed here for RAID 1 issue on Raspi for OMV:
    Lost RAID1 after reboot


    ppps: just in case the post is not there any longer: here the solution for mounting each time you boot USB drive script on a raspberry pi (raspi):
    Fix Raspberry Pi 2 Mounting Issues
    Thanks to Jake for bringing this to my attention. Apparently there is a bug in the Pi 2 that messes up automounting. You can fix it by creating a delay.
    Open up the /boot/cmdline.txt file
    sudo nano /boot/cmdline.txtAdd this line to the bottom, you can increase this delay if necessary
    rootdelay=5Hit Ctrl+X, Y and Enter to save and exit, then reboot to see if it automounts now.
    If the Raspberry Pi hard drive still does not automount we can use rc.local (thanks Julian)
    sudo nano /etc/rc.localAdd this lines before the exit line
    sleep 30sudo mount -aexitCtrl+X, Y and Enter to save
    Reboot again to test
    sudo reboot


    Enjoy Raspi!

    ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !

  • well, well, well.
    Clearly unstable even with the work around above.
    Some boot the USB are mounted fine and some boot the USB are not mounted.
    Still looking for a reliable workaround...

    ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !

  • I have done the following:


    added "auto" in the FSTAB right after "defaults,"


    and put the delay to 8 in /boot/cmdLine.txt and delay to 35 in rc.local sleep 35 .


    I will test a week with this settings...



    and rc.local



    and the cdmline.txt



    Code
    dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
    rootdelay=8


    I will post back to let you know about stability.

    ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !

  • hi there!
    is there anyway that we can somehow automate this with a plugin or something?
    I have lately added an USB disc to my OMV setup to extend the disc space, and somehow its got disconnected after 10-12 days. Which nowadays I'm resolving with an reboot.
    Thanks!


    The USB disc is listed in /etc/fstab

  • Dear sir,


    Generally there is a problem with mounting external usb drives with omv images in Raspberry ...!! Try to load an official image from the raspberry page and then try to install omv with terminal commands ,if it is possible, later and after the updates.! More stable I think...!! Please post if you have something new....

    • Offizieller Beitrag

    Generally there is a problem with mounting external usb drives with omv images in Raspberry

    Please stop posting this misinformation. Most people do not have the problems you are having.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • ryecoaaron
    I would not be so straightforward and sure about the fact it is not widely spread...
    - ie that USB external should connect on boot.
    And that only very few people have the issue. It would be interesting to have a poll ! :))
    -at least I do have the problem...


    FYI: I run about 5 to 6 Rpi (all Rpi3) at all time and I am still trying to understand why some Rpi do boot with USB external drive 100% of the time fine and some not...And I noticed that some would not boot fstab samba shares either while some other of my Rpi would boot fine on the very same network and same system and config... strange isn't it?.



    arxaios
    Only one of my Rpi (my NAS!) out of the 6 runs OMV stonerbuner. The others do run on Raspbian Jessie and some of them have the very same problem. So I think, I can say that the issue is not OMV related. But I noticed this issue is high certainly with Wheezie...(even CUPS is a problem on Wheezy, rats!) and the image of OMV stonerburner runs on Wheezie! I really doubt USB drive connection at boot is an OMV issue. It is a system issue. Most probably a boot-up sequence order issue...



    I have noticed that using a clean image of Raspbian 'tends' to improve the situation, yes, it is true. The last 6 SD I flashed (for me and friends) with a new Raspbian where stable with usb connect and samba share connect at boot time - yeah!!.
    So I have less issue "statistically" when I re-install from a clean image -at least on Jessie- than if I do some upgrade...
    Several of my SD are Jessie upgraded from Wheezie and yes I can say that most of them will have issue booting USB share.
    So from my little experience I would say: system issue / Wheezie issue translated into a Jessie issue when upgarded -rats again!.
    Or may be I do something wrong... but if so, why the "sudo mount -a" works 100% ...?
    weird!
    As "sudo mount- a" forces a re-read of fstab... why it shoudl work when I SSH and not at boot time?
    So I suspect it is an issue of how the boot order sequence is done really - the "mount -a" arrives too early in the boot sequence and something is missing for mounting all properly. It seems to be the most realistic issue for me.
    And this is issue "may" be inherited when upgrade a Wheezie to Jessie.



    keksznet
    Yes, even with the above tricks USB external drive gets disconected twice a month for me usually for no reason I can understand on my OMV stoneburner (Wheezie)...


    Using delay in rc.d and/or cdmline.txt certainly helps (it was every day before adding the delays!) but it is not foolproof...yet.
    I am investigating a further forced-delayed-mount using cron on user level as user is the last in boot sequence so all daemon should be up and running properly.
    I will report when/if I have some results or improvement.

    ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !

    • Offizieller Beitrag

    I would not be so straightforward and sure about the fact it is not widely spread...
    - ie that USB external should connect on boot.
    And that only very few people have the issue. It would be interesting to have a poll ! :))
    -at least I do have the problem...

    Run a poll. Not sure what you are trying to accomplish with it though. Other than my own experience creating and maintaining the image for a couple of years, there are lot of people using the image. Look at the number of downloads on sourceforge. Based on those downloads, there are relatively few people complaining about those issues.


    I think some of the following are issues:


    1 - People having the problem are probably using the same (or same family) usb-to-sata chipset
    2 - Due to the low power consumption of an RPi, most people don't shut it down and avoid the issue.
    3 - Some are trying to power the drive directly from the usb port on the RPi with a power supply that is too small to power both.
    4 - People using multi-drive usb enclosures are probably seeing the RPi boot before the enclosure is ready.


    Should there be a delay in cmdline.txt by default? Maybe but why punish the people not seeing the problem with a longer boot time.


    Or may be I do something wrong... but if so, why the "sudo mount -a" works 100% ...?
    weird!
    As "sudo mount- a" forces a re-read of fstab... why it shoudl work when I SSH and not at boot time?

    This just proves that it is a timing issue. The faster an RPi boots, the more likely a slower spinup or initializing usb drive will not get mounted. The drives that get disconnected seems to be an issue with Linux support of how the controller sleeps. I've never had a usb stick not mount either.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • @ ryecoaaron


    I was kidding about the poll. ;)


    1 - People having the problem are probably using the same (or same family) usb-to-sata chipset
    -Good point. I will have a check around this.
    here are mine for my 2 2To disks:
    FYI:
    Bus 001 Device 005: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge
    Bus 001 Device 006: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge


    2 - Due to the low power consumption of an RPi, most people don't shut it down and avoid the issue.
    -yes, it is probably true.
    FYI:mine must reboot everyday via a root-cron programmed job.


    3 - Some are trying to power the drive directly from the usb port on the RPi with a power supply that is too small to power both.
    Agree. All drives must externally powered.
    FYI:All my drives are externally powered.


    4 - People using multi-drive usb enclosures are probably seeing the RPi boot before the enclosure is ready.
    Not quite sure about this point.
    In my case the drives (and the rpi) are always on power.
    Just the pi is asked to reboot. So the drives and the usb-sata chipset should be ready and the drives spinning when Rpi boots up and call for them.


    You are right usb-stick always mount...even in Wheezy.


    More thoughts into this issue, I must have.


    Thanks Ryecoaaron.


    Ps: in the back of my mind, I wonder is systemd has not improved the boot-up sequence on the fresh Debian8 images? Which would give the impression that it is smoother with Jessie...

    ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !

    • Offizieller Beitrag

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

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