Вопросы Теги

Разрешения NTFS, потерянные на корневом уровне

Я заметил, что у меня нет разрешений a+x на одном из дисков / разделов (что у меня было пару дней назад, я не знаю, как я их потерял). Однако, чтобы что-то сделать, я попытался создать папку на этом диске с терминала в качестве суперпользователя, используя эту команду: > cd /media/progyadeep/New Volume ##New Volume is the drive > sudo mkdir "NEW"

, но я не могу. Я вижу это сообщение об ошибке:

mkdir: cannot create directory ‘/media/progyadeep/New Volume/NEW’: Read-only file system

Я даже попытался открыть окно проводника с помощью

sudo -i nautilus

, но я не могу создавать файлы / папки даже из графического интерфейса, открытого как суперпользователя .

ПОЧЕМУ?

Как я могу исправить эту проблему? Как Ubuntu стал настолько отчаянным, что обманывал даже суперпользователя?

EDIT 1

Этот вопрос был идентифицирован как возможный дубликат этого вопроса: потерял все разрешения для моего раздела NTFS. Тем не менее, основная проблема заключается в том, что я не могу вернуть разрешения, используя метод, показанный там. Как заметил кто-то в комментариях, диск, защищенный от записи, может создать совершенно другую проблему, которая не возникла в другом вопросе.

EDIT 2

Как запрошено Потерял все разрешения для моего раздела NTFS , вот вывод sudo lsblk:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda4 8:4 0 138.6G 0 part / ├─sda2 8:2 0 128M 0 part ├─sda9 8:9 0 7.9G 0 part [SWAP] ├─sda7 8:7 0 10.5G 0 part ├─sda5 8:5 0 625G 0 part /media/progyadeep/New Volume ├─sda3 8:3 0 147.5G 0 part /media/progyadeep/OS ├─sda1 8:1 0 500M 0 part /boot/efi ├─sda8 8:8 0 1.1G 0 part └─sda6 8:6 0 450M 0 part

РЕДАКТИРОВАТЬ 3

Вот результат работы mount -l, как задал @dessert:

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=4012328k,nr_inodes=1003082,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=806920k,mode=755) /dev/sda4 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1915) mqueue on /dev/mqueue type mqueue (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) /dev/sda3 on /media/progyadeep/OS type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) [OS] /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname mixed,errors=remount-ro) [ESP] /dev/sda5 on /media/progyadeep/New Volume type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096) [New Volume] tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=806920k,mode=700,uid=1000,gid=1000) gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

1
задан 15 August 2017 в 11:25

6 ответов

Отвечая на мой вопрос

После того, как решения, предложенные разными людьми, не смогли решить проблему, я углубился в исследование и, наконец, выяснил, почему вещи, которые должны были работать, не работали в моем случае потому что на моем жестком диске возникла некоторая проблема, вызванная Windows (да, у меня установлена ​​обе ОС). (Спасибо за ответ Стивена Анджелико за то, что он действительно помог найти реальную проблему. +1!) Итак, я сделал команду ntfsfix, которая якобы очистила эти файлы (или что-то в этом роде), которые остановили ubuntu от изменения вещей. Я исправил эту проблему с помощью 

sudo ntfsfix /dev/sda5

. После этого я открыл /etc/fstab в gedit и просто изменил значение -ro, рядом с /dev/sda3, на -rw и просто смонтировал, используя 

sudo mount -a

После завершения работы я восстановил права на -rw / a+x на диске на уровне пользователя.

Точка будет отмечена

Хотя я исправил проблему с разрешением на одном из дисков, я до сих пор не смог ее решить на ОС Windows. Когда я попробовал ntfsfix на диске ОС Windows, я увидел следующее сообщение об ошибке: 

sudo umount -a
sudo ntfsfix /dev/sda3

Mounting volume... Windows is hibernated, refused to mount.
FAILED
Attempting to correct errors... 
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Windows is hibernated, refused to mount.
Remount failed: Operation not permitted

Я несколько раз закрывал окна, но я продолжаю видеть это сообщение.

EDIT

Как было предложено @Stephen Angelico, Я несколько раз закрывал окна, но я продолжаю видеть это сообщение. [!d11 ]. После отключения быстрой загрузки с панели управления я перезагрузился в ubuntu и выполнил те же операции на диске ОС Windows, как и на другом диске, и успешно смонтировал его с разрешениями -rw.

0
ответ дан 22 May 2018 в 19:31
  • 1
    Проблема с диском Windows заключается в том, что Windows 10 по умолчанию будет фактически спящим, а не выключением, несмотря на ярлык с надписью «Shut down». Это можно устранить, отключив быструю загрузку в Windows (извините, но я не знаю, как), но, конечно, это повлияет на время загрузки Windows. – Stephen Angelico 14 August 2017 в 17:28
  • 2
    @StephenAngelico Все, что мне было нужно, - это поиск в google и «Как отключить быструю загрузку на WIndows 10». Тада !! – progyammer 14 August 2017 в 17:51

Отвечая на мой вопрос

После того, как решения, предложенные разными людьми, не смогли решить проблему, я углубился в исследование и, наконец, выяснил, почему вещи, которые должны были работать, не работали в моем случае потому что на моем жестком диске возникла некоторая проблема, вызванная Windows (да, у меня установлена ​​обе ОС). (Спасибо за ответ Стивена Анджелико за то, что он действительно помог найти реальную проблему. +1!) Итак, я сделал команду ntfsfix, которая якобы очистила эти файлы (или что-то в этом роде), которые остановили ubuntu от изменения вещей. Я исправил эту проблему с помощью

sudo ntfsfix /dev/sda5

. После этого я открыл /etc/fstab в gedit и просто изменил значение -ro, рядом с /dev/sda3, на -rw и просто смонтировал, используя

sudo mount -a

После завершения работы я восстановил права на -rw / a+x на диске на уровне пользователя.

Точка будет отмечена

Хотя я исправил проблему с разрешением на одном из дисков, я до сих пор не смог ее решить на ОС Windows. Когда я попробовал ntfsfix на диске ОС Windows, я увидел следующее сообщение об ошибке:

sudo umount -a sudo ntfsfix /dev/sda3 Mounting volume... Windows is hibernated, refused to mount. FAILED Attempting to correct errors... Processing $MFT and $MFTMirr... Reading $MFT... OK Reading $MFTMirr... OK Comparing $MFTMirr to $MFT... OK Processing of $MFT and $MFTMirr completed successfully. Setting required flags on partition... OK Going to empty the journal ($LogFile)... OK Windows is hibernated, refused to mount. Remount failed: Operation not permitted

Я несколько раз закрывал окна, но я продолжаю видеть это сообщение.

EDIT

Как было предложено @Stephen Angelico, Я несколько раз закрывал окна, но я продолжаю видеть это сообщение. . После отключения быстрой загрузки с панели управления я перезагрузился в ubuntu и выполнил те же операции на диске ОС Windows, как и на другом диске, и успешно смонтировал его с разрешениями -rw.

0
ответ дан 18 July 2018 в 08:35

Отвечая на мой вопрос

После того, как решения, предложенные разными людьми, не смогли решить проблему, я углубился в исследование и, наконец, выяснил, почему вещи, которые должны были работать, не работали в моем случае потому что на моем жестком диске возникла некоторая проблема, вызванная Windows (да, у меня установлена ​​обе ОС). (Спасибо за ответ Стивена Анджелико за то, что он действительно помог найти реальную проблему. +1!) Итак, я сделал команду ntfsfix, которая якобы очистила эти файлы (или что-то в этом роде), которые остановили ubuntu от изменения вещей. Я исправил эту проблему с помощью

sudo ntfsfix /dev/sda5

. После этого я открыл /etc/fstab в gedit и просто изменил значение -ro, рядом с /dev/sda3, на -rw и просто смонтировал, используя

sudo mount -a

После завершения работы я восстановил права на -rw / a+x на диске на уровне пользователя.

Точка будет отмечена

Хотя я исправил проблему с разрешением на одном из дисков, я до сих пор не смог ее решить на ОС Windows. Когда я попробовал ntfsfix на диске ОС Windows, я увидел следующее сообщение об ошибке:

sudo umount -a sudo ntfsfix /dev/sda3 Mounting volume... Windows is hibernated, refused to mount. FAILED Attempting to correct errors... Processing $MFT and $MFTMirr... Reading $MFT... OK Reading $MFTMirr... OK Comparing $MFTMirr to $MFT... OK Processing of $MFT and $MFTMirr completed successfully. Setting required flags on partition... OK Going to empty the journal ($LogFile)... OK Windows is hibernated, refused to mount. Remount failed: Operation not permitted

Я несколько раз закрывал окна, но я продолжаю видеть это сообщение.

EDIT

Как было предложено @Stephen Angelico, Я несколько раз закрывал окна, но я продолжаю видеть это сообщение. . После отключения быстрой загрузки с панели управления я перезагрузился в ubuntu и выполнил те же операции на диске ОС Windows, как и на другом диске, и успешно смонтировал его с разрешениями -rw.

0
ответ дан 24 July 2018 в 19:07
Read-only file system

Это, скорее всего, произошло из-за некоторой проблемы на диске. Большинство систем используют errors=remount-ro (в случае ошибок, перемонтировать как только для чтения) в локальных файловых системах, чтобы предотвратить повреждение и / или потерю данных. Поэтому может возникнуть проблема с самим приводом. Проверьте потерю данных, потому что (по крайней мере, в моем опыте) это часто происходит, когда привод терпит неудачу. Даже remount-ro не может остановить сам привод. Если это так, вам может потребоваться следующее: вернуть данные с помощью инструментов восстановления данных на основе Linux

Если ваш жесткий диск не работает, я могу предложить только проверку оборудования по всей линии или просмотр /var/log/kern.log или dmesg для любых конкретных деталей файловой системы. Я не могу придумать никаких других причин, по которым он устанавливается только для чтения.

2
ответ дан 22 May 2018 в 19:31
  • 1
    Мой ноутбук является новым, поэтому я сомневаюсь, что мой HDD не работает. И я новичок в Linux, поэтому я мог видеть только греческий, когда открывал kern.log или dmesg. Может быть, это будет иметь смысл для вас. Посмотрите: (1) dmesg (2) kern.log – progyammer 14 August 2017 в 15:41
Read-only file system

Это, скорее всего, произошло из-за некоторой проблемы на диске. Большинство систем используют errors=remount-ro (в случае ошибок, перемонтировать как только для чтения) в локальных файловых системах, чтобы предотвратить повреждение и / или потерю данных. Поэтому может возникнуть проблема с самим приводом. Проверьте потерю данных, потому что (по крайней мере, в моем опыте) это часто происходит, когда привод терпит неудачу. Даже remount-ro не может остановить сам привод. Если это так, вам может потребоваться следующее: вернуть данные с помощью инструментов восстановления данных на основе Linux

Если ваш жесткий диск не работает, я могу предложить только проверку оборудования по всей линии или просмотр /var/log/kern.log или dmesg для любых конкретных деталей файловой системы. Я не могу придумать никаких других причин, по которым он устанавливается только для чтения.

2
ответ дан 18 July 2018 в 08:35
Read-only file system

Это, скорее всего, произошло из-за некоторой проблемы на диске. Большинство систем используют errors=remount-ro (в случае ошибок, перемонтировать как только для чтения) в локальных файловых системах, чтобы предотвратить повреждение и / или потерю данных. Поэтому может возникнуть проблема с самим приводом. Проверьте потерю данных, потому что (по крайней мере, в моем опыте) это часто происходит, когда привод терпит неудачу. Даже remount-ro не может остановить сам привод. Если это так, вам может потребоваться следующее: вернуть данные с помощью инструментов восстановления данных на основе Linux

Если ваш жесткий диск не работает, я могу предложить только проверку оборудования по всей линии или просмотр /var/log/kern.log или dmesg для любых конкретных деталей файловой системы. Я не могу придумать никаких других причин, по которым он устанавливается только для чтения.

2
ответ дан 24 July 2018 в 19:07
  • 1
    Мой ноутбук является новым, поэтому я сомневаюсь, что мой HDD не работает. И я новичок в Linux, поэтому я мог видеть только греческий, когда открывал kern.log или dmesg. Может быть, это будет иметь смысл для вас. Посмотрите: (1) dmesg (2) kern.log – progyammer 14 August 2017 в 15:41

Другие вопросы по тегам:

Похожие вопросы: