NTFS and FAT partitions mounted with executable bits create lots of annoyance

Oops, I think I made a mistake:

Instead of dmask=000 and fmask=111, make that:
dmask=222 (reading and executable bits for directories)
fmask=333 (only reading bits for files).

I can confirm this for Edgy

This could have an adverse effect on wine users who want to execute programs from their Windows partition, but this may be the minority of people.

Does it? I've just disabled the executable bit from a .exe which I have and the command "wine program.exe" still works perfectly.

And, even with wine installed on my system and the executable bit enabled, executing directly the file (with "./program.exe") does not work at all.

I don't think I understand in which way changing the executable bit could affect wine users.

It seems that you can't actually execute anything from an NTFS partition anyway (though you can from vfat): clicking on a program in Nautilus silently fails, while the command line says it can't find it (amd64 gutsy):

$ ls -l
...
-rwxrwxrwx 1 root root 188797 2007-03-16 16:15 rebecca
...
$ ./rebecca
bash: ./rebecca: No such file or directory

('rebecca' is a program I wrote, which lived in my Windows partition as it also has a Windows version compiled from the same source; it ran fine from there on my old Win98(vfat)/Ubuntu machine.)

While probably a bug in itself, this does mean that the above fix for the "executable text file" message (which I agree is annoying, and far more likely to be encountered by less knowledgeable users) wouldn't actually change anything on NTFS.

PS. I think you do mean dmask=000,fmask=111. dmask=222,fmask=333 appears to forbid writing to that partition.

Disregard previous comment-my problem turned out to be that I was trying to run a 32-bit program with a 64-bit library, after recompiling to 64-bit it ran fine from NTFS. Possibly an unhelpful error message, but nothing to do with NTFS. Sorry.

I've just found there already is a Nautilus option to turn off the "executable text file" message: Edit > Preferences > Behaviour > View executable text files when they are opened.

Turning this on does prevent scripts from being run from Nautilus, as the Nautilus right-click menu doesn't have a "run" option, but it would seem unlikely that a new user would want to do this.

This would appear to be a duplicate of Nautilus bug #14335.

Can anyone provide any good reason for leaving the executable bits on FAT and NTFS partitions?
It just makes people annoyed, especially new users coming from Windows and wanting to read something from their Windows partition.

Reasons for this bug being classified as a papercut:
- simple to fix - just change the default umask
- affects lots of users

In Ubuntu, we intentionally set things up using binfmt-support so that
users don't have to know to explicitly invoke things using wine; they
can just execute the .exe file directly. (Or, if we don't do this right
now, this is a regression from previous releases and we should fix it;
we certainly do this for .NET executables using Mono.) Disabling the
executable bit would forcibly remove this feature.

Considering that the alternative is fixing what's little more than a
cosmetic bug in Nautilus - all you'd need to do would be to arrange for
Nautilus to act as if that "View executable text files when they are
opened" option is set when the filesystem is mounted umask=007 or
whatever - I'd rather fix Nautilus than change the installer. Changing
the installer for this kind of thing tends to be more difficult to
reverse later when we discover we did the wrong thing. In any case, you
have to fix Nautilus anyway in order to cope with upgraded systems.

Accordingly, I'm reassigning this bug to Nautilus and declining the
installer change.

Colin: this is probably a stupid question, but are you sure that binfmt-support depends on exe files having the executable bit set?

"In Ubuntu, we intentionally set things up using binfmt-support so that
users don't have to know to explicitly invoke things using wine; they
can just execute the .exe file directly."
AFAIR, having wine as the default app for .exe (just like gedit is for .txt) is enough - exe files can be run just by double-clicking. No need for +x for the whole fat partition, no change for users' expectations.
Besides, when you have a Windows app installed on a Linux partition then you won't benefit from +x on fat/ntfs - you will still have to set +x manually or open it with wine (double clicking or by CLI).

why no only an extra entry on nautilus like 'Run'

for both .exe and .bin and .run...

something that says 'Start Application' quite simple.

Colin & all,

the vast majority of stuff on a vfat drive -particularly a usb/flash removable one - is not executable. Having the X bit set for this data is basically wrong and leads to problems when (for example) doing a restore of data previously copied to the drive for backup as all the restored data is given the executable flag. Its just wrong on so many levels to add an execute bit to everything just to maybe help a couple of not terribly popular (AFAIK) applications.

There needs to be a change to the default to rw-r--r-- and a relatively clear way to change the default to one of the other potentially useful masks such as rw-rw-rw, rwxr-xr-x or rwxrwxrwx. Currently I am not at all clear how to set the default behavior - I can set the behavior for particular volumes which is mostly OK, as a workaround but is annoying when I'm given (for example) a flash drive from a colleague to copy data from. In this case what happens is all the documents I copy across get the X bit set which sometimes ends up meaning that they execute instead of open the application

Colin: I noticed you're not subscribed to this bug, so our comments haven't actually reached you. Please read them, there are questions for you.

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

- This bug is regarding changing the behavior for the partition as a whole , while the problem arises only for the text files.
While I would agree that the present behavior is a problem. The solution presented here is not ideal.
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Members subscribed to this bug might be interested in Bug #425166 , which is to change the behavior only for the text files , while preserving the .exe functionality. Which is a more ideal way.

Just for completeness another annoyance caused by this bug/feature:

- i put a SD-card (vfat) from my digicam in the card-reader
- all pictures get execute-permission because it's vfat
- i copy the pictures to a samba-share of my NAS, permissions get preserved = all pics have execute-bit on the samba-share
- the windows-PCs in the LAN can't view the pictures because the NAS (QNAP TS-109, newest firmware) defaults to "map hidden = yes" in the smb.conf (meaning the DOS-attribute "hidden" is read from the unix attribute "group-execute", aka all group-executable files are hidden to windows-explorer)

took me 30 minutes to figure that out and i'm somewhat experienced with windows, linux & samba.

Hi all,

Just wanted to mention a further annoyance:

I have a few scripts rigged up to backup my /home folder to an external hard drive (which is FAT32). I recently did a fresh install of Ubuntu 9.10, which I then copied (restored) my files from the external hard drive, and I just recently noticed everything having the +x bit set.

I should have done a little more research I suppose on this issue before trusting FAT32 to holding my files.

I've created a semi-fix for anyone with a similar problem:
$ find . -perm /+x -type f -print0 | xargs -0 chmod -c -x

That command should recursively work with the current directory down and remove the "x" bit from any file, excluding folders.

The only dilemma I'm facing now is a way to avoid removing the "+x" bit from legitimate files (executables, scripts, etc) that need it.

Slackware users seem to have this problem addressed long time ago:
            "There's no need for normal files to be executable (and it can indeed be a security risk (*)), so we use fmask
            to turn off those permissions."
and proposed solutions, depending on the case, in
http://slackwiki.org/Windows_Partitions

(*) And, in the other hand, the annoyances described in
https://bugs.launchpad.net/hundredpapercuts/+bug/78505/comments/8
https://bugs.launchpad.net/hundredpapercuts/+bug/78505/comments/14
https://bugs.launchpad.net/hundredpapercuts/+bug/78505/comments/17
https://bugs.launchpad.net/hundredpapercuts/+bug/78505/comments/18