Question

0

Partition will not mount Automatically

rated 0 times [ 0] [ 0] / answers: 1 / hits: 1353 / 3 Years ago, sat, august 14, 2021, 1:24:03

The original problem was that a new disk that I installed a month ago, did not mount after a reboot, yes a month later. From Disk UI, I click "mount selected portion" and nothing happens, no error reported. Also, from Disk UI, I click the gears icon, then I click "check Filesystem..."
and it returns "Filesystem Disk_4TB on ST4000DM005-2DP166 is undamaged.".

devconnected provided instructions to mount from the command line.

sudo mount /dev/sda1 /Disk_4TB

This works fine, so the modified questions are

Why automatically mount failing given entry in fstab.

Should I report a bug that the GUI fails to mount and fails to indicate any error code? If so, where do I do this?

**$ sudo gdisk -l /dev/sda**

[sudo] password for john: 

GPT fdisk (gdisk) version 1.0.5



Partition table scan:

  MBR: protective

  BSD: not present

  APM: not present

  GPT: present



Found valid GPT with protective MBR; using GPT.

Disk /dev/sda: 7814037168 sectors, 3.6 TiB

Model: ST4000DM005-2DP1

Sector size (logical/physical): 512/4096 bytes

Disk identifier (GUID): 27569B50-D174-424A-A7BF-4A0E7353C4D9

Partition table holds up to 128 entries

Main partition table begins at sector 2 and ends at sector 33

First usable sector is 34, last usable sector is 7814037134

Partitions will be aligned on 2048-sector boundaries

Total free space is 3693 sectors (1.8 MiB)



Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048      7814035455   3.6 TiB     8300  Basic data partition

$ lsblk -f
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
loop0 squashfs 0 100% /snap/canonical-livepatch/95
loop1 squashfs 0 100% /snap/core/10859
loop2 squashfs 0 100% /snap/core/10823
loop3 squashfs 0 100% /snap/core18/1944
loop4 squashfs 0 100% /snap/gnome-3-34-1804/66
loop5 squashfs 0 100% /snap/core18/1988
loop6 squashfs 0 100% /snap/gtk-common-themes/1506
loop7 squashfs 0 100% /snap/gnome-3-34-1804/60
loop8 squashfs 0 100% /snap/gtk-common-themes/1514
loop9 squashfs 0 100% /snap/microk8s/2035
loop10 squashfs 0 100% /snap/microk8s/2074
loop11 squashfs 0 100% /snap/snap-store/467
loop12 squashfs 0 100% /snap/snapd/11107
loop13 squashfs 0 100% /snap/snap-store/518
loop14 squashfs 0 100% /snap/snapd/11036
sda

└─sda1 ext4 Disk_4TB c4eaf980-50c9-4c49-9d73-3855be4c91f9

sdb

└─sdb1 ext4 External_2TB a8500ff3-9465-4238-9ada-22ab9ec590ae 1.7T 0% /External_2TB
nvme0n1 ext4 Disk2 16352634-91e0-4567-92cf-065e01395794 757.1G 54% /Disk2
nvme1n1

├─nvme1n1p1 vfat 112E-F7FA 511M 0% /boot/efi
├─nvme1n1p2

└─nvme1n1p5 LVM2_member 4bj3wl-VTM6-f16H-8gXR-bQLV-1Dj0-vtSulI

├─vgubuntu-root ext4 f1ab115e-a7b7-4737-b62d-2a6cca1a1016 692G 19% /
└─vgubuntu-swap_1 swap 1418c65e-e718-49af-a1a5-57f78209480e [SWAP]

cat /etc/fstab

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

/dev/mapper/vgubuntu-root /               ext4    errors=remount-ro 0       1

# /boot/efi was on /dev/nvme1n1p1 during installation

UUID=112E-F7FA  /boot/efi       vfat    umask=0777      0       1

/dev/mapper/vgubuntu-swap_1 none            swap    sw              0       0

/dev/disk/by-uuid/16352634-91e0-4567-92cf-065e01395794 /Disk2 auto suid,nodev,nofail,x-gvfs-show,auto,exec,rw 0 0

/dev/disk/by-id/usb-BUFFALO_External_HDD_020100005036-0:0-part1 /External_2TB auto nosuid,nodev,nofail,x-gvfs-show 0 0

/dev/disk/by-uuid/92D6CA0AD6C9EE93 /Disk_4TB auto nosuid,nodev,nofail,x-gvfs-show 0 0

/dev/disk/by-uuid/c4eaf980-50c9-4c49-9d73-3855be4c91f9 /Disk_4TB auto nosuid,nodev,nofail,x-gvfs-show 0 0

SOLVED
Wayne observed that /Disk_4TB in fstab had 2 entries with different UUIDs?

I once installed the disk with one of those docking stations before later installed it internally. This creates a second entry in fstab with different UID.

Disk UI did not complain about the conflicting stale entry and succeeded in mounting it the first time around. Subsequent reboots is when this conflict kicks in.