ドライブ/パーティションの1つにa+x
権限がないことに気付きました(数日前に持っていました。どのようにそれらを失ったのかわかりません)。しかし、何かを成し遂げるために、このコマンドを使用して、ターミナルからsuperuserとしてそのドライブにフォルダーを作成してみました:
> 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
しかし、superuserとして開かれたGUIからでもファイル/フォルダを作成できません。
この問題を修正するにはどうすればよいですか? Ubuntuはどうしてスーパーユーザーさえもcheすほどに必死になったのですか?
この質問は、この質問の重複の可能性として識別されました: NTFSパーティションに対するすべてのアクセス許可を失います 。ただし、主な問題は、そこに示されている方法を使用して許可を取り戻すことができないことです。コメントで誰かが指摘したように、書き込み保護されているドライブは、他の質問では発生しなかったまったく異なる問題をここで構築している可能性があります。
@ wjandrea で求められているように、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
@ dessert が要求するmount -l
の出力は次のとおりです。
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)
さまざまな人から提案された解決策が問題を解決できなかった後、私は深く研究し、最終的にはうまくいかなければならないことが私のケースではうまくいかなかった理由を見つけましたWindows(はい、両方のOSがインストールされています)。 (Stephen Angelico のおかげで、実際の問題を見つけるのに本当に役立ちました。+ 1!)そのため、ubuntuが物事を変更するのを阻止したファイル(またはそのようなもの)をクリアしたコマンドntfsfix
を使用しました。私はその問題を修正しました
Sudo ntfsfix /dev/sda5
その後、/etc/fstab
をgedit
で開き、-ro
の横にある/dev/sda3
の値を-rw
に変更し、単に[
Sudo mount -a
シャットダウン後、ユーザーレベルでドライブの-rw
/a+x
権限を取り戻しました。
ドライブの1つで権限の問題を修正しましたが、WindowsのOSドライブではまだ解決できませんでした。 Windows OSドライブでntfsfix
を試したときに、次のエラーメッセージが表示されました。
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
ウィンドウを数回シャットダウンしましたが、このメッセージが表示され続けます。
@ Stephen Angelico 、で示唆されているように、Windows 10ではデフォルトで「高速起動」オプションが有効になっているため、「シャットダウン」をクリックするたびに実際に休止状態になります。コントロールパネルから高速ブートを無効にした後、ubuntuを再起動し、他のドライブと同じ操作をWindows OSドライブで実行し、-rw
権限で正常にマウントしました。
Read-only file system
これは、おそらくドライブの問題が原因で発生しました。ほとんどのシステムではerrors=remount-ro
(エラーの場合、読み取り専用として再マウント)データの損傷や損失を防ぐために、ローカルファイルシステムに。したがって、ドライブ自体に問題がある可能性があります。 (少なくとも私の経験では)これはドライブの障害時に頻繁に発生するため、データの損失を確認してください。 remount-ro
は、ドライブ自体の障害を止めることはできません。この場合、これが必要になる可能性があります。 Linuxベースのデータ回復ツールを使用してデータを取り戻す
ハードドライブに障害が発生していない場合は、すべてのハードウェアをチェックするか、/var/log/kern.log
またはdmesg
は、ファイルシステムの特定の詳細を示します。読み取り専用としてマウントする他の理由は考えられません。