MKV files mistakenly identified as executable on network shares

[grexe]

(please change the title accordingly, I don't know why I only noticed/checked MKV files, this applies to all files on all my NFS drives - suggested title: Files with user:group other than 1000:1000 are treated as executables ).

Tracker displays and treats files on my NFSv4 network shares as executables and I cannot select a suitable app for opening them as a consequence. When manually opening, e.g., a PDF document with BePDF, it's displayed just fine.

I get the warning message that they are wrongly marked as executable and if I wanted to fix that, but it doesn't help.

When inspecting the file information using "Get Info" and checking permissions, I see that files with user/group 1000:1000 with owner r/w/x permissions can at least be opened with the default app correctly, but they are still displayed with a generic text icon and a "Kind" attribute of "Generic file".

This behaviour is inconsistent and wrong. A PDF is a PDF no matter the permissions, so file types should be deduced accordingly (they are readable after all).

Using today's nightly hrev58442.

[waddlesplash]

What does the permissions display show?

[grexe]

Owner has r/w/x. User/group 3000 set to server-managed share:share. Access works fine, just the display is wrong.

[waddlesplash]

Are you sure the display is wrong? If the "x" bit is set, then Tracker's behavior is expected.

[waddlesplash]

I am still not sure the behavior you are describing is the problem here. It may just be the NFS driver misbehaving. And if the files have mode "X", then Tracker is behaving as it should.

[KitsunePrefecture]

Dear grexe,

If 'x' is set for files - not directories - that means the OS treats as executable on Posix OSes. So Tracker is right. You must remove 'x' right from single files which ones are not binary executables.

Itwas possibly added a

chmod 777 on every files and directories. For fixing this you must go into your NAS or server which contains the network shares, and issue a chmod 664 <-- read/write the owner/group, read others or chmod 644 <-- read/write the owner, read group/others

So for that the files treated as executables the ball is on your side .. Tracker really works as expected.

From directories - do not remove the executable rights, as that means no access for the given owner/group/others. These are the most common access rights chmod 775 [ĐIR] <-- read/write/access the owner/group, read/access others chmod 770 [ĐIR] <-- read/write/access the owner/group chmod 755 [ĐIR] <-- read/write/access the owner, read/access group/others chmod 750 [ĐIR] <-- read/write/access the owner, read/access group chmod 700 [ĐIR] <-- read/write/access the owner

There are some mspecial cases, when you are access grants to list files in a directory chmod 751 [ĐIR] <-- read/write/access the owner, read/access group, access only for others chmod 711 [ĐIR] <-- read/write/access the owner, access only for group/others

This way they can only list the content of a directory but no access for the enlisted files nor access as reading neither access to modify them .. just enlist them.

I hope I helped to understand how Posix access rights works, to help fix these files settings on your storage place.

Kind regards

[nephele]

I doubt posix permissions are the problem here.

grexe: please give the output of listattr -v myFile before and after asking tracker to identify it.

We can't do much if your share mistakenly adds +x (might be a setting for a permission mask) but I suspect this is just tracker unable beeing able to set extended attributtes to idenify the file and us not activating an attribute overlay to bypass that.

[grexe]

@KitsunePrefecture hey thanks for the refresher but I still remember the UNIX course from my CS studies and am an avid Linux user since 1997:) It's true that the POSIX permissions affect the file type and subsequentially the way Tracker handles them. However they look fine in Linux, so I doubt it's the NAS' fault (TrueNAS SCALE 24.10), but I'll check this.

@nephele thanks, good suggestion, you mean "-l" for the verbose output btw;-) I don't see any attributes before or after, it's always:

 listattr -l Ariva_202E-Satreceiver.pdf 
File: Ariva_202E-Satreceiver.pdf
        Type       Size  Name                                Contents
-------------------------------------------------------------------------------

0 bytes total in attributes.

[grexe]

2 network shares with different permissions resulting in wrong detection of type