5

Using Kubuntu 17.04. I cant add or delete files from my internal HDD. The HDD is mounted via Dolphin and shows that I am the owner and I have permission to read/write to it.

But if I remount it using

 sudo mount -o remount,rw '/media/salu/B66697C066978033'

then I am able to write to the HDD.

My queston is why I cant write when mounted through Dolphin? And how do I get Dolphin to mount it correctly on its own

Here is some extra information to help you guys solve my problem.

Output for fdisk -l :

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xe782d87a

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1  *          2048     206847     204800   100M  7 
HPFS/NTFS/exFAT
/dev/sda2           206848  212721663  212514816 101.3G  7 HPFS/NTFS/exFAT
/dev/sda3        212721664 1881840590 1669118927 795.9G  7 HPFS/NTFS/exFAT
/dev/sda4       1881841662 1953523711   71682050  34.2G  5 Extended
/dev/sda5       1881841664 1953523711   71682048  34.2G 83 Linux

Also the output for ps aux | grep udisks :

root      1306  0.0  0.3 454544 11888 ?        Ssl  Oct07   0:07 
/usr/lib/udisks2/udisksd --no-debug
root      2932  0.0  0.8  50008 35032 ?        Ss   Oct07   0:29 
/sbin/mount.ntfs /dev/sda2 /media/salu/28B017A7B0177B10 -o 
rw,nodev,nosuid,uid=1000,gid=1000,uhelper=udisks2
root     27542  0.0  0.0  14500  2424 ?        Ss   23:35   0:00 
/sbin/mount.ntfs /dev/sda3 /media/salu/B66697C066978033 -o 
rw,nodev,nosuid,uid=1000,gid=1000,uhelper=udisks2

2 Answers2

5

Ok, I solved the problem. Its not a problem related to Dolphin. Apparently I couldnt write even after re-mounting. So when I used mount -o rw /dev/sda3 /media/salu/dcommand it gave me the following error message:

Metadata kept in Windows cache, refused to mount.
Failed to mount '/dev/sda5': Operation not permitted
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.

Note: (/media/"username"/"folder name") path is different for everyone)

The solution to this problem is given in the link below:

Unable to mount Windows (NTFS) filesystem due to hibernation


A short summary of what I did (summarized from the link):

Open Windows 10 and disable "fast startup"

  1. Open Control Panel in the small icons view and click on Power Options.
  2. Click on Choose what the power buttons do.
  3. Click on Change settings that are currently unavailable.
  4. Uncheck "Turn on fast startup (recommended)".

Also disable hibernation in Windows 10

Open an elevated Command Prompt (right click on the shortcut, click on “Run as Administrator”), and input:

powercfg /h off

Shutdown Windows and boot back in Ubuntu. You should be able to write in your drive now.

Check out the details and the full explanation of the solution in the link

-1

Although the workaround with removing the data that marks the drive as "please don't change anything" through the official way of letting windows remove it may work in some cases, this might not be possible (as it was for me) because the operating system that is installed on the drive in question can cease to function and thus a solution that works directly without having to rely on a different system might be preferable (not to mention faster and your only option).

With root priviliges, you can accomplish essentially the same thing by running your file manager with sudo in front. In the case of Dolphin, this is no longer possible as of version 17.04 but you could either edit the code and compile Dolphin yourself or use a different file manager that allows being executed as root like Nemo or Nautilus.

LukasFun
  • 161
  • 1
    This is a spectacularly bad suggestion. Every single file you write or update this way, will be accessible only to the root user afterwards, and not to any other users. This in turn will force you to constantly work with these files with sudo privileges (necessarily, every day more and more files will be impacted this way). Soon you will be forced to do all of your everyday work as root. This is compromising a major security feature of linux. See a thorough walkaround about the problem here: https://askubuntu.com/a/1316408 (the relevant part is after the title "ownership and permissions"). – Levente Jan 18 '23 at 11:05
  • That wasn't the case for me. Although that could be because I just copied files from one partition to another? Anyway, one can always just use chown to give ownership back to the originally intended user. – LukasFun Jan 19 '23 at 16:57
  • Also, is there a different way even? In my case the partition in question could not be made accessible through windows giving up control. – LukasFun Jan 19 '23 at 17:04
  • 1
    If you can keep track of which files had been impacted and subsequently chown them back to your own user, then it's kinda understandable; who haven't done such a thing. But it shouldn't be celebrated as a viable workaround for everyday use. One also needs to be aware that while one is running the graphical file manager with sudo it may write its own configuration files and those will also end up being owned by root then: so when you later try to launch the same program with your regular user, even the program may run into glitches because of file permission issues. – Levente Jan 19 '23 at 17:13