Can't mount external drives after updating kernel

Yes, sorry for that :smile:.

total 56
drwxr-xr-x 2 root root  4096 Apr  4 19:11 data
drwxrwxrwx 1 root root 12288 Mar 24 15:52 Data
drwxrwxrwx 1 root root 40960 Apr  5 21:34 Fun

I noticed something weird. The files and folders inside any of the main directory of 2 drives can be partially modified, but any subfolder can’t be.
For example: /mnt/Fun/<file 1>or<folder 1> (This <file 1> or <folder 1> in the main directory can be copied, cut, renamed and deleted, but can’t be tagged, duplicated or compressed).
But, /mnt/Fun/<folder 1>/<file 2>or<folder 2> (This <file 2> or <folder 2> inside the <folder 1> can’t be modified, it can only be copied).

The most likely cause is ntfs file system errors or limitations.

Or there is something we don’t know about the ntfs3 kernel driver.

Looking at NTFS3 — The Linux Kernel documentation

Only add one option at a time.Then do

 sudo systemctl daemon-reload
  • Add iocharset=utf8
  • Add 'umask=0000`

Do you mean adding iocharset=utf8 inside one mount file, then reload and add inside the another mount file of the second drive? And I add only to the mount files, not the auto mount?

I really have no idea why but I suspect it is relates to ntfs internals

This is a good option to add in any case

Options=rw,noatime,iocharset=utf8

Save and reload and test the mount

This creates everything rwx

Options=rw,noatime,iocharset=utf8,umask=0000

Save and reload

Only test with one mount unit - when you got it right - you can apply the same set of options to the other unit.

Prevent names incompatible with Windows

Options=rw,noatime,iocharset=utf8,umask=0000,windows_names

Save and reload
ACL - it shouldn’t be necessary but since ntfs3 is biting back we need to at least try this

Options=rw,noatime,iocharset=utf8,umask=0000,windows_names,acl

Save and reload

I am going offline for today - have fun :grin:

I think this works, finally :joy:. I don’t know what does umask=0000 make? And is it dangerous to files or anything?
I tried it with systemd method and then disabled those file and moved them to another folder to test it on fstab. And till now it works fine. I’ll deeply try it and if I found any wrong, I’ll post it. Thank you so much for help.

@soundofthunder Thank you so much for your patience and help, I really appreciate your efforts.

1 Like

umask=0000 ensures everything is rwx for user,group,other - and no it is not dangereous ntfs device but it would be quite unsafe on a Linux filesystem - it corresponds to chmod 0777 <path-or-name> or chmod ugo+rwx <path-or-name>.

The default umask for filesystems on Manjaro is 0022 which translates to u=rwx,g=rx,o=rx

I have learned something as well - something I wouldn’t have been able to otherwise - I don’t use Windows - I don’t have any disks with Windows generated NTFS filesystems - so you helped me learn as well - so thank you.

What I think I have learned is:

The ntfs3 kernel driver applies some kind of ACL and that ACL is not inherited from the mountpoint but is read from the filesystem inside the mountpoint.

drwxrwxrwx 1 root root 12288 Mar 24 15:52 Data
drwxrwxrwx 1 root root 40960 Apr  5 21:34 Fun

If I had such ntfs device I would look deeper into the file tree and look at folder and file permission below /mnt/Data and /mnt/Fun

The umask tells the ntfs3 driver to apply read,write,execute on everything that is available on the device.

The execute is necesary only for folders - otherwise you wouldn’t be able to navigate the filesystem.
The other is are self explainatory.

It is possible to experiment with the umask - remember default is 0022
Get current value

 $ umask
0022

Translate translate to human form

 $ umask -S
u=rwx,g=rx,o=rx

Set mask to rw only

 $ umask 0222

Translate setting to human form

 $ umask -S
u=rx,g=rx,o=rx

Set back to 0022

 $ umask 0022

Translate setting to human form

 $ umask -S
u=rwx,g=rx,o=rx
1 Like

I am trying to do that, I found something.
When I make the systemd method, the existing files and folder ownership is root, but still I can control them as far as I test them. And the new created folder or files are owned by me as a user. On fstab method, it’s all owned by me except for a file I was trying on it in the terminal with sudo command to cut it, may be this changed the permissions of the file.
May be because in fstab I use this line with uid=1000?

defaults,rw,noatime,iocharset=utf8,umask=000,uid=1000,gid=1000 0 0

Second, the existing folders and files permissions are:

drwxrwxrwx 1 root  root 
-rwxrwxrwx 1 root  root 

And for the new folders and files:

drwxr-xr-x 1 minaw minaw
-rw-r--r-- 1 minaw minaw

I don’t know if that’s normal or not.

This is normal the normal mode for a user on Manjaro Linux.

Okay, so, for any new files or folders these are the permissions, right?

And for the root permissions when I use systemd method?

I don’t think you should read too much into those permissions - ntfs permissions do not apply - it is likely on for show.

You could try creating some test files in the root of one of the devices.

  • List the permissions
  • Unmount
  • Remount
  • List permissions

My immediate thought is that when you remount and list permissions they will be rwx for all.

Perhaps boot into Windows and see what the Properties → Security tab has to say about the files.

Since we apply an umask=0000 we are telling the ntifs3 driver that it shouldn’t care about who does what.

I actually don’t care about the permissions. All I want to have control ob my data. I just ask to avoid any errors in the future.

Another question, if you don’t mind. In the systemd method, we add a line of the time after which the inactive drive will be unmounted. When I press on the drive again, will it request a password to mount it? As it requested from me the sudo password.

And if I want o mimic the systemd files in fstab, will this line be efficient?

defaults,rw,noatime,iocharset=utf8,umask=000,uid=1000,gid=1000 0 0

There is no permissions on NTFS when handled by Linux.

Whether you prefer one over the other doesn’t matter - but drop the uid and gid.

Always use the simplest set of options - K.I.S.S - it makes no sense to write NTFS with uid and gid and at the same time use umask 0000.

The simplest form of the options

defaults,rw,noatime,iocharset=utf8,umask=000

The kernel driver obviously requires the umask to be set in the options to be able to write to the device.

So, the permissions on ntfs on Linux are not accurate or don’t five precise info about the files authorities, right?

Okay, that makes the ownership root again, but still can control them. So, I think it’s right that they are not accurate.

I’ll just drop this here.

Linux permissions do not work on NTFS. Fine.

Any permissions you think you’re assigning to the NTFS volume (through fstab, for example) are only being applied to the mount point folders - not the NTFS volume itself - this is normal when using NTFS volumes.

This is purely for extra clarification.

Apart from that you seem to have everything working as expected now.
That’s good to see.

Cheers.

I got it now. It’s very clear. Thanks.

Yes, thank you so much for help.

Cheers.

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.