стандартный совет - смотри dmesg и smart

диски переводятся в read-only, когда есть проблемы с ФС или самим диском (badblocks, например)

hdd новые, одному 3 месяца, второму 4 дня, бедблоков нет

значит смотри dmesg

dmesg - что и как с ним «едят»?

выполни sudo dmesg -T > ~/Desktop/dmesg_file и содержимое файла, появившегося на раб столе, залей на https://pastebin.com

shmell@lmde:~$ sudo dmesg -T > ~/Desktop/dmesg_file bash: /home/shmell/Desktop/dmesg_file: Нет такого файла или каталога shmell@lmde:~$ sudo dmesg -T > ~/Desktop/dmesg_file bash: /home/shmell/Desktop/dmesg_file: Нет такого файла или каталога shmell@lmde:~$ sudo dmesg -T > ~/Рабочий стол/dmesg_file [sudo] пароль для shmell:
dmesg: неправильное использование Try ‘dmesg –help’ for more information.

подскажите, что делать

перезагрузись - авось само починится.

Зачем для dmesg использовать sudo? Зачем советовать что-то записать на диск, если у ТС «нет доступа»?

Просто в терминале запустите dmesg и смотрите вывод, если в терминале нет прокрутки, отправьте вывод в просмоторщик ″dmesg | less″. Ищите строки, где пишется про error или read only...

Поменять владельца и группу невозможно.

Откуда у вас возиникла идея поменять владельца и группу корня? Вы уже раньше подобное делали?

Зачем для dmesg использовать sudo?

Наверное поэтому:

dmesg: read kernel buffer failed: Операция не позволена

В дисковой утилите GNOME 42.0 UDisks 2.9.4 (сборка от 2.9.4) в параметрах подключения, строка «rw,notail,relatime,x-gvfs-show» была без пробелов, поставил пробелы - всё наладилось, с диска удаляю/записываю. На втором диске такой «фокус» почему то не прошёл …

Какие ещё пробелы ты туда поставил? Их там не должно быть. А то, что утилита позволила тебе их туда вписать - это баг (в утилите), где-то битый конфиг получился.

вот такой fstab, может что то поправить?

UUID=1A64-41D0 /boot/efi vfat umask=0077 0 1 /swapfile none swap sw 0 0 UUID=44649d5a-5cca-445a-b307-d1508abed363 / ext4 errors=remount-ro,x-gvfs-show,x-gvfs-name=Linux 0 1

UUID=ae31d2fa-c30a-45af-9030-d9d6dbf2e5a8 /mnt/sdb1 ext4 nosuid,nodev,nofail,x-gvfs-show 0 0

UUID=127B47FE40577E3B /mnt/sde1 ntfs rw,notail,relatime,x-gvfs-show 0 0

UUID=12F6666AF6664E53 /mnt/sda3 ntfs-3g nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=win10 0 0

UUID=3FEE0A34583ABDCA /mnt/sdc1 ntfs rw,notail,relatime,x-gvfs-show 0 0

насчёт сохранения на рабочий стол - признаю, погорячился :)

ну а dmesg давно уже в debian-based требует sudo

Я как-то проглядел что речь про ntfs. И к каким именно дискам пропал доступ, а к каким остался?

Пропал - для всех, или рут может там файлы создавать?

доступ пропал к ntfs-дискам: (на SSD несколько разделов - с win 10 и linux mint), 2 отдельных hdd с ntfs. Потом, как писал выше, «с пробелами», как получилось - не знаю, но доступ запись/удаление появился на старом диске sde1. С sdc1 - не вышло. Проблему я победил, рассказываю как. Сейчас на всех дисках у меня есть полный доступ - чтение/удаление/запись. Я просто переткнул (поменял местами) hdd sdc1 на 2Tb с SATA0 с SSD с системами, который исторически сложилось был на SATA1. Перегрузился и вот, всё Ок. Спасибо за внимание

Почему так получилось?

Отформатируй сообщение. Не понятно у тебя там перенос строки сломался или ты криво сюда вставил.

Пиши так:

```
тут твой текст
```

и сообщение будет выглядеть так:

тут твой текст

Хорошо. В следующий раз постараюсь. А по теме, что исправился глюк с доступом к дискам?

Да кто сейчас определит почему. Ведь не было зафиксировано, что именно было проблемой. Если считать, что проблемой были опции монтирования, то, возможно, изменение имён дисков стало причиной пересоздания каких-нибудь конфигов. В современных системах /etc/fstab ведь «сбоку», монтирование через юниты systemd или вобще отдельными утилитами...

Или у вас банально был плохой контакт в SATA шлейфе, ошибки чтения, переключение на низкую скорость и перемонтирование в readonly. И помогло просто перетыкание шлейфов, а не перемена дисков местами.

В шлейфах уверен на 99,9%, что контакт хороший. Это было видно по значительной скорости запись/чтение, близкой к теоретической-расчетной. А вот «косяки» с монтированием очень даже возможны… Всё равно спасибо сообществу за помощь!

ну а dmesg давно уже в debian-based требует sudo

Не только. Во всех вменяемых дистрах он требует повышенные привилегии, что есть правильно.

А вот убрать это дело можно опцией ядра kernel.dmesg_restrict=0, но делать это не очень рекомендуют, ибо секурность все дела.