[SOLVED] Txt files copied from macOS are executable, why\?

[Linuz]

My macbook pro mid-2012 13-inch computer died recently.

I moved over all my files in the "Documents" folder from the home directory of my Mac OSX over to my Documents directory in Linux Mint.

All my text files kept getting that prompt to open them as executables! Grrrr

Guess moving .txt files over from Mac OSX to Linux Mint causes Linux Mint to treat them as executables. Thankfully right-clicking and deselecting the checkbox in the permissions tab for "allow executing file as program" was all I needed to do.

Thanks all for explaining this to everyone on the internet!

Now the real question to ask is why .txt files created in Mac OSX wind up becoming treated as executables on Linux Mint.

[xenopeek]

why .txt files created in Mac OSX wind up becoming treated as executables on Linux Mint

Probably — same as for NTFS partitions — if you on the fly mounted the HFS+ partition in Linux Mint, without specifying options, same default permissions were used for all files on the partition and that means all text files would also have been marked as executable. But also every other file you copied from there. Do a check on that. If you copied any documents or images for example, give them a right-click and check on Properties > Permissions if they are marked as executable?

Using non-Linux filesystems with Linux can work fine but usually requires fine-tuning mount options to prevent all files from being made executable — they are made executable because of the incompatible filesystem which implements file permissions in a different way so to let you execute files on that filesystem it just assumes all files are executable. A usual mount option is to make none of the files executable.

Anyway. If you have the copied files in directories where there should be no executable files, it is possible to remove these permissions in one go. In your file manager browse to the directory where you have the files. Right-click an empty spot in the directory and from the context menu select "Open in Terminal". Confirm you're in the right directory (the directory is noted in the prompt; or type pwd command to see the full path of the current directory). Then run this command:
find . -type f -exec chmod -x -c {} \;
That finds all the files in the current directory and subdirectories, and removes the execute permission from each. It prints what it does for each file changed. You can first run find . -type f to see the list of files it will process.

[Linuz]

why .txt files created in Mac OSX wind up becoming treated as executables on Linux Mint

Probably — same as for NTFS partitions — if you on the fly mounted the HFS+ partition in Linux Mint, without specifying options, same default permissions were used for all files on the partition and that means all text files would also have been marked as executable. But also every other file you copied from there. Do a check on that. If you copied any documents or images for example, give them a right-click and check on Properties > Permissions if they are marked as executable?

Using non-Linux filesystems with Linux can work fine but usually requires fine-tuning mount options to prevent all files from being made executable — they are made executable because of the incompatible filesystem which implements file permissions in a different way so to let you execute files on that filesystem it just assumes all files are executable. A usual mount option is to make none of the files executable.

Anyway. If you have the copied files in directories where there should be no executable files, it is possible to remove these permissions in one go. In your file manager browse to the directory where you have the files. Right-click an empty spot in the directory and from the context menu select "Open in Terminal". Confirm you're in the right directory (the directory is noted in the prompt; or type pwd command to see the full path of the current directory). Then run this command:
find . -type f -exec chmod -x -c {} \;
That finds all the files in the current directory and subdirectories, and removes the execute permission from each. It prints what it does for each file changed. You can first run find . -type f to see the list of files it will process.

Forgot to mention that I had transferred my documents from Mac OSX to Linux Min using an NTFS drive. So the drive being partitioned as NTFS could have had something to do with that too.

[xenopeek]

So the drive being partitioned as NTFS could have had something to do with that too.

That is the cause of this issue. As detailed above, you can fix all the copied files in one go with a little work.

[Linuz]

So the drive being partitioned as NTFS could have had something to do with that too.

That is the cause of this issue. As detailed above, you can fix all the copied files in one go with a little work.

Very cool! I will try out those two commands you suggested to remove the executable status of my simple text files inherited from my macbook pro.

Did you split off my question from the original thread? What was the URL for the original thread so I have it for reference? Want to read more about the interaction between NTFS drives and Linux.

Thank you!

[xenopeek]

Did you split off my question from the original thread?

Yes. As per our forum rules, don't add new questions to solved topics and don't revive topics older than 6 months. The topic you replied to was both.

The logs don't show from which topic it was split but I think I found it in my browser history:
viewtopic.php?t=271125

[Linuz]

Did you split off my question from the original thread?

Yes. As per our forum rules, don't add new questions to solved topics and don't revive topics older than 6 months. The topic you replied to was both.

The logs don't show from which topic it was split but I think I found it in my browser history:
viewtopic.php?t=271125

Ok, thanks for explaining that. Guess it's easier to find answers in threads about a single topic.

[Termy]

All files in NTFS in Linux are treated as with a mode of 777, which is rwxrwxrwx in its symbolic form, meaning everyone has read, write, and execute rights to that file; this is probably the primary reason why people like me will generally recommend that you use a Linux filesystem, such as the Extension variants (IE: EXT4).

The downside is, of course, that Windows can't read Linux filesystems, at least not natively; unless that has been somehow addressed, perhaps with WSL. I imagine most people just put regular, non-sensitive data on NTFS drives, and keep the rest on a Linux FS. I have some films on a couple of NTFS drives, but everything else is EXT4.

[rene]

All files in NTFS in Linux are treated as with a mode of 777, which is rwxrwxrwx in its symbol form, meaning everyone has read, write, and execute rights to that file

Note though that is in essence easily adjusted through mount options; a problem is that the automounter makes it non-trivial to in fact specify mount options but for /etc/fstab mounts it's easily done. I.e., for a permanently mounted NTFS partitions you can for example have something like

Code: Select all

UUID=12345678-1234	/windows/c	ntfs-3g	uid=myusername,fmask=133,dmask=022

The masks are to be read 7-complement; above gets you 644 (rw-r--r--) for files, 755 (rwxr-xr-x) for directories and has things as such quite a bit more sane.

For non-permanent, automounted filesystems you can moreover have e.g. similarly

Code: Select all

UUID=12345678-1234	/mnt/usbstick	ntfs-3g	noauto,uid=myusername,fmask=133,dmask=022

and would see the automounter still honour things. Bit of a pain in the sense of that UUID or LABEL changing on a reformat, which may be frequent on something like a USB stick. Recently noticed that an upcoming version of udisks2 will allow for more general configuration of the autmounter as well: viewtopic.php?p=2022654#p2022654

[Termy]

...

Nice. I always thought it was a hard limit, but it's nice to know there are mount options to set a given mode for files in NTFS. It's a shame you have to do it via '/etc/fstab' or when manually mounting the FS, though. Still, it's not bad for a FS not native to Linux. I noticed some interesting and disconcerting things, when I recently enabled NTFS support in the kernel:

• The kernel seems to only have so-called "experimental" write support for NTFS.
• The kernel documentation points out that writing in NTFS in Linux can cause data loss.
• You can compile the kernel with only read support for NTFS, which I've done.

Moral of the story? Stick with Linux filesystems, if you can. Anecdotally speaking, if I've yet to ever experience any write problems with NTFS in Linux, but I've not used NTFS extensively, aside from watching some films.

[rene]

The (current; a new kernelspace NTFS driver from Paragon is about to get merged) kernelspace NTFS driver is not much use indeed but that's also the reason it's not in fact being used. NTFS-3G is a FUSE driver, i.e., operates fully in userspace and on specifically Ubuntu/Mint the type "ntfs" has in fact for some time now been an alias for "ntfs-3g" (in the sense that mount.ntfs for example is a link to mount.ntfs-3g). That's to say you could've in fact compiled the kernel without support for NTFS, period.

I believe the new Paragon kernelspace driver will be referred to as "ntfs3" just so as to not confuse the matter even further...

[Termy]

...

You're quite right! I had no idea. Thanks for the awesome tip. I'll recompile the kernel without NTFS support and just use the 'ntfs-3g' package. Gold star to you.

[Linuz]

why .txt files created in Mac OSX wind up becoming treated as executables on Linux Mint

Probably — same as for NTFS partitions — if you on the fly mounted the HFS+ partition in Linux Mint, without specifying options, same default permissions were used for all files on the partition and that means all text files would also have been marked as executable. But also every other file you copied from there. Do a check on that. If you copied any documents or images for example, give them a right-click and check on Properties > Permissions if they are marked as executable?

Using non-Linux filesystems with Linux can work fine but usually requires fine-tuning mount options to prevent all files from being made executable — they are made executable because of the incompatible filesystem which implements file permissions in a different way so to let you execute files on that filesystem it just assumes all files are executable. A usual mount option is to make none of the files executable.

Anyway. If you have the copied files in directories where there should be no executable files, it is possible to remove these permissions in one go. In your file manager browse to the directory where you have the files. Right-click an empty spot in the directory and from the context menu select "Open in Terminal". Confirm you're in the right directory (the directory is noted in the prompt; or type pwd command to see the full path of the current directory). Then run this command:
find . -type f -exec chmod -x -c {} \;
That finds all the files in the current directory and subdirectories, and removes the execute permission from each. It prints what it does for each file changed. You can first run find . -type f to see the list of files it will process.

That was a spendid treat to watch that terminal command crunch through all the text files so quickly!

Thank you very much for sharing that command! I have built up a mental library of a few terminal commands over the years, but esoteric-looking stuff you provided certainly did the trick!

I really ought to pay for a live tutorial class on using Linux terminal like a pro. It's so nice not to have to do things one a time manually...

...

...

Moral of the story? Stick with Linux filesystems, if you can. Anecdotally speaking, if I've yet to ever experience any write problems with NTFS in Linux, but I've not used NTFS extensively, aside from watching some films.

Yes, you're definitely right. I'll stick with free software file systems and avoid proprietary ones like NTFS, APFS, HFS+ etc. going forward. Linux is designed to be interoperable. Windows and Mac OSX are designed to keep you in their walled gardens. No thank you!