I noticed that I don't have a+x permissions on one of the drives/partitions (which I had a couple of days back; I don't know how I lost them). However, to get something done, I tried creating a folder in that drive from the terminal as superuser, using this command:

> cd /media/progyadeep/New Volume        ##New Volume is the drive

> sudo mkdir "NEW"

but I can't. I see this error message:

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

I even tried opening an explorer window with

sudo -i nautilus

but I can't create files/folders even from the GUI opened as superuser.


How can I fix this issue? How did Ubuntu become so desperate as to cheat even the superuser??


This question was identified as a possible duplicate of this question: Lost all permissions to my NTFS partition. However, the main problem is that I can't regain permissionsusing the method shown there. As pointed out by someone in the comments, the drive being write protected might be building up an entirely different issue over here which didn't arise in the other question.


As asked for by @wjandrea, here's the output of sudo lsblk:

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 


Here's the output of mount -l, as asked for by @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
    it sure looks like you've got the drive/device mounted as read-only. type in mount & you'll likely discover its (ro) – guiverc Aug 13 '17 at 7:58
  • @guiverc I did have some mounting issues recently. Should I change something in /etc/fstab/ to mount it as -rw? Because -rw doesn't seem to work with the mount command in the terminal for me. – progyammer Aug 13 '17 at 8:01
  • 1
    Possible duplicate of Lost all permissions to my NTFS partition – Zanna Aug 13 '17 at 8:01
  • it's write protected, first remove the write protection from the drive – Suraj Kumar Aug 13 '17 at 10:33
  • 1
    Do we speak about a usb drive/stick, sd card or an internal hdd here? The former sometimes have a little switch to enable read-only access. Your output of lsblk is really weird: most of these partitions don't seem to be mounted, and most importantly none at /media/progyadeep/New Volume. Was it mounted when you executed the command? Could you give us the output of mount -l please? – dessert Aug 14 '17 at 6:46

Read-only file system

This most likely happened because of some problem on the drive. Most systems use errors=remount-ro (in case of errors, remount as read-only) on local filesystems to prevent data damage and/or loss. Therefore there may be a problem with the drive itself. Check for data loss, because (at least in my experience) this often happens as a drive is failing. Even remount-ro can't stop the drive itself failing. If this is the case, you might need this: Get Your Data Back with Linux-Based Data Recovery Tools

If your hard drive is not failing, I can only suggest checking hardware all along the line or looking at /var/log/kern.log or dmesg for any specific details on the filesystem. I can't think of any other reason for it mounting as read-only.

  • My laptop is new so I doubt if my HDD is failing. And I'm new to linux so I could only see greek when I opened kern.log or dmesg. Maybe those will make sense to you. Take a look: (1) dmesg (2) kern.log – progyammer Aug 14 '17 at 12:41

Answering my own question

After solutions suggested by different people failed to fix the issue, I went deep into research and finally found out why the things that should have worked didn't work in my case is because there was some problem on my hard drive that was caused due to Windows (yes, I have both OS's installed). (Thanks to Stephen Angelico's answer for it really helped to find out the real problem. +1! ) So what I did was used the command ntfsfix that supposedly cleared those files (or something like that) that stopped ubuntu from modifying things. I fixed that issue with

sudo ntfsfix /dev/sda5

After this, I opened up /etc/fstab in gedit and simply changed the value -ro, beside /dev/sda3, to -rw and simply mounted using

sudo mount -a

After a shutdown, I have regained -rw/a+x permissions on the drive at user level.

Point to be noted

Although I have fixed the permission issue on one of the drives, I still haven't been able to solve it on the Windows' OS drive. When I tried ntfsfix on the Windows OS drive, I saw the following error message:

sudo umount -a
sudo ntfsfix /dev/sda3

Mounting volume... Windows is hibernated, refused to mount.
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

I have shut down windows several times but I keep on seeing this message.


As suggested by @Stephen Angelico, Windows 10 has the "fast boot" option enabled by default which causes it to actually hibernate every time we click on "shut down". After disabling the fast boot from the control panel, I rebooted into ubuntu and did the same operations on the Windows OS drive as I did in the other drive and successfully mounted it with -rw permissions.

  • The problem with the Windows drive is that Windows 10 by default will in fact hibernate instead of shutting down, despite the label saying "Shut down". This can be fixed by disabling fast boot in Windows (sorry but I don't know how), but of course this will impact boot times to Windows. – Stephen Angelico Aug 14 '17 at 14:28
  • 1
    @StephenAngelico All I needed was a google search on "How to disable fast boot on WIndows 10". Tada!! – progyammer Aug 14 '17 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.