I've got a Drobo in three partitions on Linux Mint, and it periodically drops off the filesystem, losing its mount points.  Upon return it disregards /etc/fstab and mounts as a new device under /media--as if I'd inserted a new USB stick.AFAICT, the fstab declarations are correct--they work manually--but maybe I've missed a key element:# drobo mount pointsUUID=d4af52ec-7734-4a43-91cf-ccea799b130e /mnt/d1 ext3 rw,user 0 2UUID=599456dd-3e9e-4f56-aa8e-957191099c6b /mnt/d2 ext3 rw,user 0 2UUID=94a0b9bf-6ae3-45cf-9a66-da228da64660 /mnt/d3 ext3 rw,user 0 2The Drobo exits uncleanly, creating a ton of false duplicates.  The only hardware is one internal drive and the Drobo.gvfsd-fuse   on  /run/user/1000/gvfs       type  fuse.gvfsd-fuse  (rw,nosuid,nodev,user=zed)/dev/sde2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev)/dev/sdf2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev)/dev/sdg2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev)/dev/sdd2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdc2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev)/dev/sdb2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev)/dev/sdh2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev)/dev/sdi2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdk2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdj2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdn2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdm2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdl2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdo2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdp2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdq2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdt2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sds2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdr2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdz2    on  /mnt/d3                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdy2    on  /mnt/d2                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdx2    on  /mnt/d1                   type  ext3             (rw,noexec,nosuid,nodev,user=zed)/dev/sdu2    on  /media/zed/drobo1         type  ext3             (rw,nosuid,nodev,uhelper=udisks2)/dev/sdw2    on  /media/zed/drobo3         type  ext3             (rw,nosuid,nodev,uhelper=udisks2)/dev/sdv2    on  /media/zed/drobo2         type  ext3             (rw,nosuid,nodev,uhelper=udisks2)When I (manually) unmount and re-mount, it follows the fstab declarations without issue.  I never need to first type umount /mnt/d*.  I don't need to be root to re-mount.The manual un-mount command works quickly.  The first re-mount command takes a few seconds and the Drobo spins back up (this I expect is the Drobo allowing the drives to sleep, but the Drobo itself is still on the filesystem).  The second and third mount commands always happen as quickly as I can type them.0 [08:57:46 zed@linnicks doc 124] umount /media/zed/drobo*0 [08:57:51 zed@linnicks doc 125] mount /mnt/d30 [08:57:56 zed@linnicks doc 126] mount /mnt/d20 [08:57:59 zed@linnicks doc 127] mount /mnt/d10 [08:58:01 zed@linnicks doc 128] Did I miss something obvious?  Thanks for reading.Additional: My main concern is why /etc/fstab is disregarded, though I might be better advised to find the root cause for the dropoffs in the first place**.  Just now it occurred to me that cron could umount and remount, but that's even more of a band-aid.It's easy to blame a 2008 Drobo for an occasional glitch.  It seems completely random.  The Drobo will work fine for a week or three and then simply be in the wrong place.  It's always all three partitions.  I've had less than stellar luck with other Drobos, so I'm quick to blame the drobo for the dropoffs--maybe I'm being too hasty there.  It's certainly worth noting that my OS theoretically should recognize the hardware and not try and define it as three new devices each time.I don't think the Drobo is merely entering sleep mode, because I can go a day or two without using it and step right back into it.**This ambiguity may be a cause for deeper concern from a back-up-your-stuff perspective, but I'm planning a better and more traditional RAID that will serve as additional backup.  Everything on RealRaid will be triplicated to Drobo, so when either one dies, I replace it and move on.  On that note if anyone has found a specific device (Qnap, Lacie...) to be highly satisfying at the consumer (possibly even prosumer) level, lemmeno.  I'm probably thinking in the 15-30TB range.I can't create the tag Drobo.  If someone with more rep feels it's appropriate, please do.
Drobo filesystem ignores /etc/fstab, automounts in the wrong place after connection is interrupted
linux;linux mint;fstab;removable storage
My main concern is why /etc/fstab is disregarded...The manual mount immediately put them right back where they should beThe auto-mounting you refer to is performed by udisks.  As you desire, it's supposed to defer to the entry in /etc/fstab, if there is one.  But if there isn't one, it mounts under /media.  It sounds like udisks gets confused by the failed (but still existing) mounts...  I would call this a bug in udisks.  If you are interested in seeing it improved then please report it to the project :).Udisks has actually been tested with device removal, as this is something real users do :).  If udisks mounts a filesystem itself, and the device is removed, it attempts to unmount the filesystem and clean up.  This unmount occurs regardless of whether a mount point is specified manually in /etc/fstab.  However, udisks does not unmount automatically if the device was mounted manually, using /sbin/mount.Hence, your scenario would not necessarily have been noticed when developers of udisks did their initial coding/testing.Note that manually running mount /dev/sdu2 behaves differently to the automount that happens when the new device is plugged in.  /sbin/mount does not call in to udisks.  (udisks might be implemented in terms of /sbin/mount though).