External Hard Drive not mounted on reboot

General Discussion
21

Can you post again cat /etc/fstab

22 
root@DietPi:~# cat /etc/fstab
# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1938M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf (VirtualBox shared folder), gluster, bind mounts
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAPFILE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=e8af6eb2-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=e8af6eb2-01 /boot vfat noatime,lazytime,rw 0 2
UUID=94BA918FBA916F0C /mnt/94BA918FBA916F0C fuseblk noatime,lazytime,rw,nofail,noauto,x-systemd.automount
root@DietPi:~#
23

ok I tried to replicate your setup. The challenge seems to be with the NTFS file system format. Probably drive manager is not setting correct values. At least following was working for me.

Let’s see if this is working for you as well. For this you would need to edit /etc/fstab file manually. (not using drive manager)

  1. open the file /etc/fstab
nano /etc/fstab
  1. now you need to go to last line and place a hash # in front of the line staring UUID=94BA918FBA916F0C
#UUID=94BA918FBA916F0C /mnt/94BA918FBA916F0C fuseblk noatime,lazytime,rw,nofail,noauto,x-systemd.automount
  1. add following line below
UUID=94BA918FBA916F0C /mnt/94BA918FBA916F0C ntfs rw,nofail,noauto,x-systemd.automount,user,fmask=133,dmask=022,uid=1000,gid=1000 0 0
  1. it should looks like this for the PHYSICAL DRIVES section now
#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=e8af6eb2-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=e8af6eb2-01 /boot vfat noatime,lazytime,rw 0 2
#UUID=94BA918FBA916F0C /mnt/94BA918FBA916F0C fuseblk noatime,lazytime,rw,nofail,noauto,x-systemd.automount
UUID=94BA918FBA916F0C /mnt/94BA918FBA916F0C ntfs rw,nofail,noauto,x-systemd.automount,user,fmask=133,dmask=022,uid=1000,gid=1000 0 0
  1. save and close the file
  2. reboot your system
  3. try to access the drive once system is online again
cd /mnt/94BA918FBA916F0C
  1. let’s see if content is there
ls -la
  1. if all goes well you should see your data
24

Finally :cry: . Now everything is working fine. Thanks a lot for your help

25

but why are you crying if all is working now :slight_smile:

MichaIng
probably we would need to have a look how NTFS volumes are mounted by drive manager

26

I’m crying from happiness. Thanks again

27

pls be careful using drive manager. This will reset your changes done on /etc/fstab

28

I have/had the same issue. This is a dietpi bug in the way Drive Manager mounts NTFS drives? or fuseblk isn’t suited for NTFS drives?

Shouldn’t this be reported?

I’m using 2xUSB external drives 1xHDD and 1xSSD, both on NTFS, reboots don’t automount the drives even though they’re listed in fstab. Dietpi recommends using Drive Manager to mount all drives, however if it doesn’t work properly (now) for NTFS, this should be fixed…

29

fuseblk is totally fine for the NTFS drives

Pls try to adjust your /etc/fstab as instructed above

If there is an issue in drive manager, it will be fixed.

30

Many thanks for reporting this issue. It should be solved with: https://github.com/MichaIng/DietPi/pull/4340

Indeed NTFS drives need to be mounted by giving “ntfs” as input filesystem type, but when checking back the mounts filesystem type, it reports “fuseblk”. The second seems to be more related to how the system/kernel needs to talk to that mount (like an API), while the first is more related to how the mount is setup (the implementation).

Good that we found this, as potentially other special filesystem types (encrypted ones, LVM and such nested filesystems) would be affected as well, if we’d create fstab entries or call “mount” for them, where the correct “input” filesystem type is required.