3

Recently, I installed Ubuntu 17.04 on a new ssd (standard installation with ext4), no other drive was connected at that time. After I connected my data hdd (ntfs formatted, it's a dual-boot setup with win7), I noticed that every single file on it got the execute flag (had a dual-boot with 14.04 before, but did not have this problem).

If I toggle the flag off on a single file, it is immediately reset. Also, every file that I copy to the hdd gets the flag and if I create a link to a hdd folder on my ssd, the link itself gets the flag after a renoot, making it unusable until I remove the flag (it is reset on the next reboot).

The entry for the ntfs drive in /proc/mounts :

dev/sdc1 /media/brad/mydata fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0
  • Why did this happen (I did not do anything that should have caused this/how to prevent it from happening next time)?
  • How do I safely undo it for the whole drive at once without touching/changing each file (also without changing file date stamps)?

Re:duplicate:

I don't see what this would have to do with chmod, I don't want to change file or folder permissions, I need to correct how ubuntu is seeing the whole drive because that has been changed and I think that change was a very bad decision. So now I have to edit fstab to get the pre-16.10 behavior back. There is no mention of this situation or of the 'correct' (old) permissions one has to set in "How do I use 'chmod' on an NTFS (or FAT32) partition?". While renaming this question to "Reverting ntfs permissions to pre-16.10" might make it more unique, somebody with the same problem does most likely not know about the reason and therefore would not find this thread, so I keep it like it is.

Still waiting for the wrong "Duplicate" note to be removed. This is how a duplicate looks: https://superuser.com/questions/512393/why-is-every-file-marked-as-an-executable-on-my-mounted-ntfs-partition

Bradzzv
  • 107
  • 3
    in short: NTFS is a porprietary Microsoft FS and does not support the flags unix filesystems usually support. This is just a way for Linux filemanagers to handle NTFS. in shorter: Just ignore the flags on NTFS, they are basically non-existant, but your filemanager have to show something. – mondjunge Aug 02 '17 at 15:11
  • Like I said, this is not how it was on earlier ubuntu versions and I can't imagine that such a change for the worse became the new default. – Bradzzv Aug 02 '17 at 15:25
  • ^^ yeah, that's exactly the reason, why I stick with LTS versions. Sorry for beeing a smartass, I wish I could help you, but I have no clue what's going on. – mondjunge Aug 02 '17 at 15:27
  • 1
    Thank you, that pretty much covered the "how did this happen" part.

    So I checked the hdd with two liveCDs: 16.10 : execute flag set for all files, 14.04.5 : no execute flag. So it seems the files are unchanged, only how the OS is seeing them has changed.

    How do I restore the 14.04 behavior? Currently I am thinking about a custom fstab entry, but I don't really need to automount the drive and don't know if it would work.

     – Bradzzv Aug 03 '17 at 14:09
  • Could you please mount one ore more NTFS file systems, run grep ntfs /proc/mounts /etc/fstab and [edit] your question to include its output? Thanks. – David Foerster Aug 26 '17 at 07:31
  • There are no entries including "ntfs" in those files, so I have added the fuseblk entry from mounts. – Bradzzv Aug 26 '17 at 11:43
  • The duplicate is the canonical post for setting permissions on NTFS partitions - its title uses chmod because that is what people typically use for setting permissions. Reading that should tell you that you should you that the correct place for mount options is /etc/fstab; as for removing execute bit, use fmask=0133,dmask=022 – muru Aug 28 '17 at 01:44
  • What duplicate means? In my opinion, if the question can be read as different meaning, it is not duplicated. if the question can have different answer, it also is not duplicated.For the question "How do I use 'chmod'..." , If I added an answer like "you can change default behavior of auto mount for external drive..." then it is wrong answer for the question. but here, if there is a way, it is the best answer for this question. – sio4 Nov 14 '17 at 16:25
  • For me, I do not want add fstab entries for all of my external USB drives, such as the answers for the linked question, but I want to change default behavior of the auto-mounter. (if there is a way to change default options for auto-mounter) The goals for the questions are different. – sio4 Nov 14 '17 at 16:29

1 Answers1

0

This answer is probably wrong, please help improving it!

Why did this happen:

Because ubuntu changed ntfs permission handling from version 16.10 onward.

How to safely undo it:

  1. Once the ntfs drive is mounted, take the current mount entry from /etc/mtab or /proc/mounts and correct it (according to "man mount.ntfs"-OPTIONS: user_id must become uid, group_id must become gid, nodev becomes no_def_opts, rw, nosuid and blksize do not seem to exist??, default_permissions becomes permissions, ) PERHAPS you also have to swap fuseblk for ntfs-3g, I don't know.
  2. add useful options:
    windows_names so creation of filenames with characters that are not allowed by windows (e.g. colons) is prohibited (this should be the default imho, but is not).
    noauto if you like to prevent automounting
  3. append the line by the desired fmask and dmask (for ntfs mount options, just using umask would result in wrong folder permissions). The "normal" permissions for files is rw-r--r-- and for directories, it is rwxr-xr-x (directories need execute permission, see https://superuser.com/questions/168578/why-a-folder-must-be-executable). According to http://www.webune.com/forums/umask-calculator.html the file permissions translate to 644 and converted to fmask that is 133, folder permissions of rwxr-xr-x translate to 755, converted to dmask that is 022.
  4. Append the result /dev/sdc1 /media/brad/mydata fuseblk no_def_opts,relatime,uid=0,gid=0,permissions,allow_other,noauto,windows_names,fmask=0133,dmask=022 0 0 to /etc/fstab (use your own paths, of course and do not add additional blanks).

Disclaimer: I still have no idea if this is safe. Could someone knowledgeable have a look, please?

..................................................................................................................................................................

old, wrong stuff, pending deletion:
/dev/sdc1 /media/brad/mydata fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,noauto,fmask=0133,dmask=022 0 0

Finally dared to try it out, but clicking on the device I get this error message Unable to access location Error mounting system-managed device /dev/sdc1:Command-line 'mount"/media/brad/mydata"'exited with non-zero exit status 32: mount: wrong fs type, bad opton, bad superblock on /dev/sdc1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. dmesg | tail did not reveal any related information.

So is there a conflict of dmask/fmask with these ominous default_permissions or do I need to use the UUID or something completely different?

Bradzzv
  • 107
  • If you want to remove execute permissions, the mask should be 0133. – muru Aug 23 '17 at 10:43
  • Sorry, I don't get it. On webune.com/forums/umask-calculator.html a umask of 0133 is not recognized by the script. I want normal file permissions like they were in the past: rw-r--r-- that is allegedly 644 and translates to umask 022. Or is that site wrong? – Bradzzv Aug 25 '17 at 22:46
  • The site is correct for umask as it is generally used, but in the mount options of NTFS, it umask does not treat files and directories differently (typically, umask masks from 777 for directories and 666 for files, but with this option, it masks from 777 for both). There are separate fmask and dmask options for more fine-grained control. (I would suggest fmask=0133,dmask=022.) – muru Aug 28 '17 at 01:41
  • I didn't check all options, but at first glance, NTFS does not have user_id or group_id options. See man mount.ntfs and check if you have used any other invalid options. – muru Sep 09 '17 at 19:48
  • So do I need to use ntfs-3g instead of fuseblk? Are the outputs of /etc/mtab or /proc/mounts completely unsuited to derive my fstab entry from? – Bradzzv Sep 10 '17 at 21:17
  • hint: do you see fuseblk being used as a type anywhere in the duplicate? The type is just ntfs, and yes, those files are not necessarily useful for fstab. – muru Sep 11 '17 at 00:19