Data SSD gone read only [Solved]

[LinuxSpring1]

Thanks LS1.

Here's the result of mount:

Code: Select all

$ mount -v
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8110380k,nr_inodes=2027595,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1630836k,mode=755,inode64)
/dev/sda2 on / type ext4 (rw,noatime,discard)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3261660k,inode64)
/dev/sda1 on /boot/efi type vfat (rw,noatime,fmask=0113,dmask=0002,allow_utime=0020,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda3 on /home type ext4 (rw,noatime,discard)
/dev/sdb1 on /home/sherbet/rootMX19 type ext4 (rw,relatime)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k,mode=755,inode64)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/run/cgmanager/agents/cgm-release-agent.systemd,name=systemd)
tmpfs on /run/user/112 type tmpfs (rw,nosuid,nodev,relatime,size=1630832k,mode=700,uid=112,gid=121,inode64)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1630832k,mode=700,uid=1000,gid=1000,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdd3 on /media/beegees/homeMX type ext4 (rw,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)
/dev/sdc1 on /media/beegees/dData type ext4 (ro,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)

And the fstab:

Code: Select all

$  cat /etc/fstab
# Pluggable devices are handled by uDev, they are not in fstab
UUID=a67d2f14-455c-428a-8115-a809d8ce6040   /                        ext4   discard,noatime                 1 1 
UUID=AFE5-F5A0                              /boot/efi                vfat   noatime,dmask=0002,fmask=0113   0 0 
UUID=90435d99-9c5a-4995-b4d7-1390b10a90fe   /home                    ext4   discard,noatime                 1 0 
/swap/swap                                  swap                     swap   defaults                        0 0 
LABEL=rootMX19                              /home/sherbet/rootMX19   ext4   defaults                        0 0  

Regarding the fstab info.

MX23 mounted OK this morning and it's the first three entries above, viz.
sda1 is /boot/efi above, UUID...F5AO.
sda2 is / above, UUID ...6040
sda3 is /home above, UUID ...98FE

Those 3 partitions are what you listed from my quick system info yesterday - when the drive was sdc, rather than sda as it is today.

....
....

Hope this info can give you more insight?

Thanks and cheers.

So today the disk has changed from sdc to sda. Hmm that is strange ideally they should not change like that. We will circle back to that later on.

About the command considering the /etc/fstab values that you had pasted use the following to remount it. This can be the quick, but not permanent fix. This will help you to continue your work.
sudo mount --verbose --source UUID=90435d99-9c5a-4995-b4d7-1390b10a90fe --target /home -o remount,rw,discard,noatime
Description of the command
--verbose = Will give you more information on what is going on
--source = This is the partition that needs to be mounted or remounted. Here we can give the UUID or the Label. since your /etc/fstab uses UUID I am going to use that. If you are more comfortable using Label then feel free to use that too.
--target: The directory in the MX23 linux system where this has to be mounted.
-o = Options to mount. This is the meat of the command and the most important. the first is remount, because we are giving this command after the partition has been mounted. If we were in a rescue mode or runlevel 1 or target 1 then we would not use this. rw this forces the partition to be mounted as read-write. For data recovery, backup we would use ro. The remaining are as per the /etc/fstab file but if you are interested in knowing more you can do man mount and see the options or in a browser search for linux manual mount.


I would request you do make 2 small changes in the /etc/fstab file. Before you make the change please keep a backup of the /etc/fstab file. For example like /etc/fstab.bkup.05Jun2024 you can use the following command for the same
sudo cp -iv /etc/fstab /etc/fstab.bkup.05Jun2024
Feel free to replace the name fstab.bkup.05Jun2024 with whatever you are comfortable with. Or what you can remember. You need not place the copy of fstab file in /etc directory you can keep it under your HOME directory too. But do not proceed forward without doing this.

Edit the file using sudo vi /etc/fstab or sudo vim /etc/fstab or whatever editor are comfortable with.

Code: Select all

# Pluggable devices are handled by uDev, they are not in fstab
# Modified for fixing the ro mounting of /home directory.
# Changed the mount check order of home and MX19 directory
UUID=a67d2f14-455c-428a-8115-a809d8ce6040   /                        ext4   discard,noatime                 1 1 
UUID=AFE5-F5A0                              /boot/efi                vfat   noatime,dmask=0002,fmask=0113   0 0 
UUID=90435d99-9c5a-4995-b4d7-1390b10a90fe   /home                    ext4   discard,noatime                 1 2 
/swap/swap                                  swap                     swap   defaults                        0 0 
LABEL=rootMX19                              /home/sherbet/rootMX19   ext4   defaults                        0 2 

There are two numbers that you have to change from to zero to two. Both of them are are for the partition of /home and /home/sherbet/rootMX19.
Or you can copy the above code, delete the existing text in the /etc/fstab and then paste it.
Again do not do this without creating a backup of /etc/fstab. Reboot and observe what happens. I want to rule out misbehaving SSD or soon to crash SSD. If you get into a repeat of your problem then before remounting /home give the command mount -v and runlevel and paste the output over here.

This leads me to the last point change of the drive from /sdc to /sda. I am ruling out that there were changes made in the order of the drive or in the UEFI/BIOS for the order of drives. Ideally this should not happen. Once a drive is identified as sdc it should be retained as sdc unless and until there is some change made. This is concerning.

Finally please keep a backup of your data in a portable drive or in cloud whatever makes you feel safe.

[m_pav]

Let's get this one thing out of the way because it's evident you're hanging onto a naming schema that died prior to 2007 and things have moved forward at pace and you've not kept up.

The very old naming schema for internal storage died well over 15 years back and we're no longer entering BIOS settings to provision a new or additional drives, so it's well past time to let go of the old nomenclature and embrace the new. While the old nomenclature is still here it serves some purpose, however, it must be relegated to 2nd or 3rd place.

The way forward is too nonsensical for us mere human beings, we're not apt to remembering UUID codes, which are 128-bit cyphers machines use to identify drives and partitions, so we need to go the simplest route, and that is partition labels.

Simply make sure every one of your drives partitions are labelled, make the labels simple, but immediately recognisable and if any are to be mounted permanently, set your mount points to match the partition labels. If you do not care to have them permanently mounted, then the File Manager will display each partition by it's label under the Devices heading, and that will put an absolute end to at least 3 levels of confusion, 128-bit Machine drive labels, vs your expectations vs file system hierarchy.

The second is drive or partition permissions vs user ID's, set or correct these as you need them to be and your last level of confusion will be eliminated.

Most Debian based builds assign the first user account with UID=1000, second = 1001, third 1002 et-al. Check the bottom few lines of the /etc/passwd file in / partition of all OS partitions on your drives, if you see anything other than 1000 for a User ID value, then that users /home dir will not be r/w to you and the . of each Unix type partition will be r/o as it should be.

My suspicion, concerning home dirs only, is that you may have added a second user account with UID-1001 and therein lies the issue, or you're trying to access a partition that is owned solely by root and you are not root, therefore the partition will be read-only. Keep in mind some Debian based distros do things a little differently to us, some for instance put the first user account at 500, and as this does not match the Debian stock User ID of 1000, the /home partition for that user will be read only.

[ornithorhynchus]

@m_pav

Thanks for the post and thanks for taking the time to make it.

What I don't yet understand is how-to allocate the necessary permissions.

I asked how to do this in a topic I created last year: viewtopic.php?t=76668&sid=8399c1463fd91 ... 642b56a7b5 And thank you for your post to that topic too.

I know how to allocate permissions to users. I don't know how to allocate permissions to labels.

I suspect my lack of understanding is on a pretty basic level. But I'll continue to pursue it.

Again, thanks for your time and efforts - both here in this thread and in your ongoing development work. Much appreciated.

Cheers.

[m_pav]

Permissions are easy, especially when you only run one OS, but if you run multiple, then you have more things to consider.
When you introduce a drive or partition with a UNIX type filesystem, to set the permissions to yourself, all you need to do is to change the permissions on the "dot" file at the root of the partition.

Using the example in the picture below, I have a directory I use for building MX ISO's. This directory is mounted at /media/DevStore, and using Gparted, it has the same label
Here is what it looks like on my daily drivers 2TB SSD. Note the partition label and the mount point use the same names.


This is how it looks when viewed through the terminal. The dot file, seen as a single " . " when viewing the file through the ls -al command belongs to the DevStore directory. and the double dot, seen as two dots, " .. " represents the directory above.


So to take ownership of any UNIX type directory, you only need to take ownership of the dot file. In this case, that would look like the following command. Be sure to replace the username in the examples below with your own, else it will throw up an error and have no effect.

Code: Select all

sudo chown username:username /media/Devstore/.

However, if the directory is not empty and it already has content, the above command will only give you r/w access to unused space in the directory. To take permissions for all the content, then you need to change the command to include all the content that exists within the directory.

Code: Select all

sudo chown -R username:username /media/DevStore/*

The -R is recursive, so the command will recurse into all directories and change permissions of all folders and file contained therein.

The principle I used in my examples is the same for all directories in your system, and I suggest you do not try to change permissions for anything in the system or at the root of the MX Filesystem. Be very selective and change only the permissions on introduced drives and partitions, e.g., an internal non-boot drive and external USB drives.

[ornithorhynchus]

@m_pav Thanks a lot for that info in the posting above. It's what I've done and everything is now working OK, including reboots.

And thanks to everyone else for your assistance as well.

I continue to maintain good and regular backups of my data files that I test periodically.

I've marked the thread as solved.

Cheers to all.