Hey, welcome to the Ubuntu MATE Community, @Harry_Roger! It's good to have you here. 
NTFS and FAT partitions are kind of strange, in the sense of their support on Linux and other Unix-like operating systems. Surprisingly, all the stuff you just described makes perfect sense, once you know the dynamics of how Linux handles these foreign file systems. Here's why:
(NOTE: If you'd rather not read a two-and-a-half page discertation about why the file system is acting wonky, just read the TL;DR section far, far below.)
Neither FAT nor NTFS records Unix-style permissions (read, write, and execute for each of the owner, the owning group, and everybody else); FAT doesn't record any such information, while NTFS records full-fledged Access Control Lists (ACLs) for each file. The ACLs can dictate that one particular user can read and write a file while another, totally different user can only execute the same file. I'm not sure whether Linux uses the ACLs from an NTFS file system (but if I had to guess, I'd guess it doesn't; user IDs on Windows vary from user IDs on Linux, and as such the ACLs would not be very useful anyway, since who knows who would get permissions to access files).
Anyway, the Linux FAT and NTFS file system drivers just fudge Unix-like file permissions on all files on the FAT or NTFS file system, since neither file system stores Unix-like file permissions. In both cases, the default is to give full read, write and execute permissions to the owner of the file system (in other words, the user who mounted the file system in the first place). The executable permission is given so that you can, hypothetically, execute some file on an FAT or NTFS file system without copying it somewhere else first (and in the case of directories, the executable permission is necessary to read the directory at all). In FAT's case, the Linux implementation gives everybody some permissions by default, usually the permissions to read and execute files but not write to them. But in NTFS's case, for reasons which are too complicated to mention here* (see footnote below if you're interested), by default permissions are given only to the owner and to nobody else. Also note that these file systems, as I've said at least three times now, cannot store Unix-style file permissions, and as such when you instruct Caja to change the permissions on any of the files, the file system won't let the change happen; the file system's got nowhere for the permissions data to go.
It's also important to note that Caja's "executable" check box will only be fully checked if everybody has execute permissions. If only the owner has execute permissions, or if only the owning group has permissions, or even if the owner and everybody but the owning group has execute permission, that checkbox will not be checked or unchecked; it will be in the so-called "inconsistent" position, which indicates that the checkbox isn't quite on and isn't quite off. The inconsistent state is usually indicated by a small dash or hyphen mark like you described originally.
So let me make sure I'm clear. I have a FAT-formatted floppy diskette which shows these permissions in Caja:
So everybody gets read and execute permissions, but only the owner has write permission.
This is Caja's Properties dialog on one of those files, specifically for the item on line 4:
As you'll notice, Caja shows that the file is "executable" by everyone. This matches our observation via Caja's Permissions column above.
Now here's an NTFS file system of mine:
And here's the Properties dialog on the fourth item on that NTFS file system (names have been changed to protect the innocent):
As you can see, only the owner has execute permission, and therefore the checkbox is in an inconsistent state. What you can't see here is that no matter how many times I try to click that checkbox, I'm never going to be able to unset the execute permission; I'd have to remount the filesystem to remove that tricky execute bit. You can see what's going on if you try to unset the execute bit via the command line; even if you try to do so as root, there's a good chance you'll get the message:
sudo chmod u-x /media/NTFS/file
chmod: changing permissions of '/media/NTFS/file': Operation not permitted
On some versions of Linux, you'll get a different error or no error at all; in the latter case, though, the change will be immediately forgotten, and that's the (somewhat) infuriating part.
TL;DR: Chances are, you won't be able to remove the execute permissions easily. Look into the mount command (specifically the -o noexec,umask=0111 option) if you're really interested. But you can at least tell Caja to ignore the permissions by going to the Caja Preferences and checking:
Assuming you didn't already try that, I hope this works for you.
EDIT: Whoops. I forgot the footnote since I got caught up in that rambling tirade. Here it is:
* The reason for the unusual permissions is a little complicated. Unlike most other file system drivers on Linux, the NTFS file system driver is usually implemented as a "userspace" file system, which means that the file system is a program like any other you'd run. (Most file systems are implemented as a kernel module and are not run like a normal program; they have to be written very carefully to ensure bad people don't do bad things to the file system, whereas userspace file system drivers are far easier to write by comparison.) One of the design goals of userspace file systems was to ensure users could write their own file system drivers and run their own file system drivers, without special privileges; normally, to mount a file system requires special privileges behind the scenes. But the problem with allowing anybody to mount a userspace file system is that if their file system driver isn't written properly, any clueless or evil person on the system can crash or even hack and take advantage of the file system in question; file systems built as a kernel module are almost always thoroughly tested to ensure that they can withstand abuse. So to prevent ill-mannered users from taking advantage of poorly written file system drivers, by default the userspace file system component (called "FUSE") gives full permissions to whoever mounted the file system, but no permissions to anybody else. Paranoid? Maybe. Either way, the NTFS file system driver doesn't override the defaults, and as such only the user who mounted the file system has any permissions to access or use the NTFS file system.
