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

9
  • 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 2, 2017 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 2, 2017 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 2, 2017 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 3, 2017 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. Aug 26, 2017 at 7:31

1 Answer 1

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?

6
  • If you want to remove execute permissions, the mask should be 0133.
    – muru
    Aug 23, 2017 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, 2017 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, 2017 at 1: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 9, 2017 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, 2017 at 21:17

Not the answer you're looking for? Browse other questions tagged .