Mounted Volume becomes inaccessible after power manager turns off screen [SOLVED]

[diapason]

I am experiencing a new occurrence in Mint 19 Cinnamon.

In power settings, I have selected never suspend but the screen is set to turn off after 15 minutes on AC and 5 minutes on battery.
When I wake the screen up and type in my password, everything comes back to life but my mounted second SSD, where I have all my data, is not accessible. I have to unmount it (password is requested to do this) and then remount it and all is again well.

This did not happen in Mint 17.3 Cinnamon. It is just irritating more than anything else and I am wondering if there is an explanation and a fix. The mount point for /dev/sda1 where Linux is installed is / and the mount point for the data drive is /dev/sdb1/Samsung 240Gb Vol

Mint 19 is a clean install to sda1 which overwrote the previous Mint 17.3 installation.

[Spearmint2]

Mint 19 is a clean install to sda1 which overwrote the previous Mint 17.3 installation.

That makes no sense to me. Clean vs Over Wrote.

Check the fstab file.

[diapason]

Thanks for the reply. Probably imprecise use of terms on my part. What I mean is that there was a working installation of Mint 17.3 on sda1. When I decided to adopt Mint 19, I selected the "replace existing installation" option when I installed it. That, as I understand it, erases everything on the partition before commencing the install and that is what I meant by "overwrite".

The output from fstab is:

# /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>
# / was on /dev/sda1 during installation
UUID=1c4e03ee-207b-46cf-b775-0f18c6a294e3 / ext4 errors=remoun$
/swapfile none swap sw $


and the output from blkid is

ian@Galago:~$ blkid
/dev/sda1: UUID="1c4e03ee-207b-46cf-b775-0f18c6a294e3" TYPE="ext4" PARTUUID="fd075e8f-01"
/dev/sdb1: LABEL="240Gb Vol" UUID="f12b7036-cf72-4ea3-9d05-6af21c74deef" TYPE="ext4" PARTUUID="00096f06-01"
ian@Galago:~$

[Spearmint2]

That all looks OK in fstab and report of blkid. So, it's a laptop, which may I assume the SSD is plugged to a USB port? May be a regression error that turns off USB port.

[diapason]

The laptop has two onboard SSDs. A Samsung 250Gb (sda1) for the OS and a Crucial 240Gb (sdb1) for the data which I back up to an external USB HDD. It was a custom build when I decided it was time to replace my ageing Sony Vaio Windows XP machine. I dislike intensely every version of Windows which came after XP and I did not want to end up locked into M$ for ever and a day. I put the money into good hardware and went feet first into Linux overnight. That was five years ago and I have not looked back.

The only thing I have noticed is that my Mint 17.3 had a swap partition whereas the Mint 19 install does not. I read somewhere that Mint 19 creates a swap file rather than a partition and, unless that missing partition is confusing the system in some way, I can't see that it would be the source of this odd behaviour, especially as I have plenty of RAM:

ian@Galago:~$ free -mt
total used free shared buff/cache available
Mem: 15963 1184 747 130 14032 14320
Swap: 2047 0 2047
Total: 18011 1184 2795
ian@Galago:~$

I have also gone through the motions of taking ownership of sdb1 again but that made no difference. As I said, it is just a minor irritation so, if there is no obvious explanation, I guess I'll just have to live with it for now.

Thanks for your input. It is appreciated.

[Spearmint2]

Was one installed under UEFI and the other under Legacy mode? I don't have an UEFI motherboard, but I've heard that those drives with OS installed under Legacy mode may not see the drive and it's OS under the UEFI mode. That probably doesn't apply here, since you obviously have both drives at first. I'm wondering though if there's some oddity where two drives may be under two separate modes in the BIOS causing this.

When I wake the screen up and type in my password, everything comes back to life but my mounted second SSD,

That's NOT just the screen being turned off, but if password required, it's entered an Sleep mode for the OS.

Is the second drive mounted when the Sleep action happens? Or just can view it in the file manager but not mounted?

[diapason]

The fact that doing a system restart with sdb1 mounted produces the same issue does tend to suggest that the computer may actually be suspending rather than the screen just being turned off even although my power management setting is never to suspend. I need to explore that a bit further.

DMIDECODE indicates that UEFI is supported
ls /sys/firmware/efi/ returns no such file or directory
efibootmgr says efi variables are not supported on the system

Presumably that confirms both installations must be under Legacy mode.

What I did notice when I did the system restart is that when I tried to access sdb1 (which was mounted when the restart was initiated), I got an error message: Could not display "/media/root/240Gb Vol" location is not a folder.

Once sdb1 had been unmounted and remounted, GParted showed its mount point as /media/root/240Gb Vol
On the other hand, when I plug in an external drive, GParted shows its mount point as /media/ian/USB STICK

Would that indicate a possible mount point or ownership issue? Does any of that help home in on the cause?

[Spearmint2]

That may be it, an ownership problem. I'm not good with CHMOD, but if you go to the Administrative section and look for Users and Groups, you should be able to assign that drive to your User profile, and have it restriced to your profile, or open to any other profile.

[philotux]

You might consider to automount /dev/sdb1 at boot and see if the problem will go away.
In order to do that, you would need to create a new entry for it in /etc/fstab. I would think the following steps will get you there. In a terminal:

Code: Select all

sudo mkdir /mnt/Data

Code: Select all

xed admin:///etc/fstab

Add the following lines to the file:

Code: Select all

# /dev/sdb1 mounted at /mnt/Data
UUID=f12b7036-cf72-4ea3-9d05-6af21c74deef /mnt/Data  ext4  defaults  0  0

save and close the file.

Code: Select all

sudo mount -a

Code: Select all

sudo chown -R $USER:$USER /mnt/Data

Now reboot and see if it will work.

Hope this helps!

[diapason]

Thanks for responding again. I have not been idle over the weekend. I did a bit of reading about chmod and chown and decided the answer probably lay there.

I found that I could not run sudo chown 755 /media/root/'240Gb Vol' However, I was able to run sudo chown 755 /media/root and that restored the mount point of sdb1 to /media/ian which I am sure it always was before. I also note that the location of all the files on sdb1 is given as /media/ian/240Gb Vol/Filename.*

Things are now behaving almost normally except that the mount point is occasionally still reverting to /media/root and I have to do the unmount/mount thing. It seems to be something to do with Firefox as it only happens after I have been accessing websites so finding the answer to that is still on the drawing board.

I have just seen a comment come in from philotux about trying automount which looks interesting so I am going to give that a try to see what happens although my practice has always been to mount the drive manually from file manager only when required.

I'm going to mark this post [SOLVED] now as I have a fair idea of what has been going on and where to keep looking to get it exactly right.

Many thanks for all your guidance. It has been much appreciated.

[diapason]

Hi, Philotux

Thanks for the suggestion. I'm certainly going to give that a try and I'll let you know the outcome.

You will see from my earlier post today that I have marked the post [SOLVED] now as the majority of the irritation has now been resolved albeit not completely.

[philotux]

Hi, Philotux

Thanks for the suggestion. I'm certainly going to give that a try and I'll let you know the outcome.
...

You are welcome!
And good luck!

cheers
philotux

[diapason]

Finally got to the bottom of it. TimeShift seems to have been the culprit. I had it set to save the images to sdb1 rather than the default sda1. When the cron job ran, it mounted sdb1 as root. I changed the TimeShift settings to store the images on sda1 and the problem has gone away.