Written 7 Sep 2026. This is a how-to, not a product card.

When the disk went read-only

apt fails, the share won't take photos, or mount shows ro after a power blip. Confirm the filesystem is read-only, copy off what you can, then remount or fsck. Don't force a write on a dying disk.

Share opens but one folder won't accept a save, and df still looks fine? That is usually Samba or ownership: when you can open the house share but can't write. Disk packed with no free gigabytes? when the computer's disk is full. SMART already FAILED or the drive clicks? when the old disk is dying. This note is the kernel protecting the filesystem: the whole mount flipped to read-only after errors or a hard power cut.

Skip until you can reach a shell

You need SSH or a keyboard and screen. Connect fails? when SSH won't connect. No fans, black screen? when the old PC won't boot. Don't yank the power again to "test" it while the house folder has no second copy.

What this is

Linux can remount a filesystem read-only when it hits I/O errors, a dirty journal after a power cut, or a dying platter. Writes fail with "Read-only file system." apt dies. The share may still open for browsing. Photos stop copying. The fix is not chmod. The fix is: prove it is read-only, check whether the disk is dying, copy what you can to a stick or another PC, then remount or run a filesystem check from a calm boot.

Step 1: prove the mount is read-only

Show how root is mounted:

findmnt -no OPTIONS /

Or:

mount | grep ' on / '

Look for ro in the options (read-only). rw means read-write. If root is still rw, check the house folder's own mount (a stay-in USB share, for example):

findmnt -no TARGET,OPTIONS /srv/share

Swap in your real share path. A quick write test also tells the story:

touch /tmp/labthrift-write-test && rm /tmp/labthrift-write-test

If that prints Read-only file system, you are on this page. If /tmp works but the share path fails, the share disk (or Samba) may be the only problem: when you can open the house share but can't write.

Step 2: read the kernel's reason

Recent disk noise:

dmesg -T | tail -n 80

Lines with Remounting filesystem read-only, I/O error, Buffer I/O error, ext4 errors, or XFS shutdown mean the kernel already decided writes are unsafe. Also check overall SMART health if you can still read the disk:

sudo smartctl -H /dev/sda

Swap sda or use nvme0n1 from lsblk -d -o NAME,SIZE,MODEL,TRAN. Install smartmontools first if needed: sudo apt install -y smartmontools (that install will fail too if root is read-only — skip it and treat the disk as untrusted). Quiet health walk while things still feel fine: see if the old disk is dying. Already FAILED or clicking: when the old disk is dying.

Step 3: stop writing, start a second copy

Don't run a long repair as your first move if the house folder has no second copy. Don't delete the only backup stick to "make room." Don't force a remount read-write just to finish a phone dump onto a dying disk.

If reads still work, copy the house folder to a USB stick or another old PC now:

• a backup of the house folder
• copy the house folder to another old computer
• format a USB stick for the house backup if the stick is blank

Reads fail mid-copy? Take what you can. Note which folders died. A partial second copy beats none. Power just came back after a blink? House recovery order: after the power comes back.

Step 4: try a calm remount only if the disk looks healthy

If SMART is PASSED, dmesg is quiet after the remount line, and you already have a second copy (or the house folder is empty), you can ask for read-write again:

sudo mount -o remount,rw /

For a separate share disk mounted elsewhere, remount that path instead of /. Then retry the write test from Step 1. If remount fails, or the kernel flips back to read-only within minutes, stop forcing writes. Treat it as when the old disk is dying.

Step 5: filesystem check from a boot USB when remount is not enough

A dirty journal after a hard power cut often needs fsck on an unmounted filesystem. You usually cannot safely fsck the live root while you are booted from it. Boot a live or installer USB, open a shell, find the partition, then check it. Stick how-tos: make a boot USB, boot from the USB, when the boot USB won't start.

From the live session (example names — use yours from lsblk):

sudo fsck -f /dev/sda2

Answer the repair prompts only if you understand the question. When in doubt, copy more data off first and ask someone who has run fsck before. After a clean check, reboot into the normal install and confirm findmnt -no OPTIONS / shows rw.

Step 6: if it keeps coming back

Read-only again after a remount or after fsck is a disk story, not a Samba story. Copy whatever is left. Plan a drive swap on a calm day: when the old disk is dying. Fresh OS on a replacement drive, then put the house folder back from the backup. Don't buy a multi-bay NAS tonight because one Marketplace filesystem flipped to ro.

What this is not

This is not Samba read only = yes in the share config (when you can open the house share but can't write). It is not a full disk with zero free bytes (when the computer's disk is full). It is not inode exhaustion while gigabytes look free (when copies fail but free space looks fine). It is not a reason to chmod -R 777 /.

What next

Second copy habit: a backup of the house folder. Quiet SMART checks later: see if the old disk is dying. After a wipe and reinstall: put the house folder back from the backup. Weekly updates failing for other reasons: when weekly updates won't install. Box feels slow before the remount: when the old PC feels slow.

Optional: jot "disk remounted read-only," the dmesg line, and where the second copy landed in Lab plan — username + passkey, no email. Skip if you just want to keep reading.

Skip

• Skip forcing remount,rw on a disk that just logged I/O errors with no second copy.
• Skip chmod -R 777 /.
• Skip buying a NAS tonight because one filesystem flipped to read-only.
• Skip dumping more phone photos onto a read-only or dying disk as the only copy.
• Skip yanking power repeatedly to "test" the remount.
• Skip fsck on the live root while you are still booted from it.