NFSv4 share is shown empty in Tracker but listed correctly in Terminal

[grexe]

There's some weird discrepancy between Tracker's NFS share handling and the actual file/folder handling as in Terminal.

This hasn't happened before, but today with latest nightly hrev58715 and a perfectly working NFSv4 share from my local TrueNAS server, I experience this:

1. mount share with 192.168.0.117:/mnt/datalake/media" /boot/home/nessie/media
2. try to open the folder in Tracker -> empty
3. try to `ls /boot/home/nessie/media" in Terminal -> works

The 2 other shares I mounted before on the same server with same mount options work fine! I often have all 3 shares mounted.

[waddlesplash]

I guess it's probably a regression from Jim906's fix in hrev58712 somehow.

Tracker sometimes displays folders as empty if it can't open a directory FD, I think? But there might be some other cause.

[grexe]

I think it is related to access rights - there are still some issues with them here, and also in Terminal I cannot write to some paths, but I can read the top-level path which is still inaccessible to Tracker.

[Jim906]

Sorry for the inconvenience, grexe.

I can reproduce the inability to write to files, although there is another discrepancy here. I can create a plain text file that shows as read-only in StyledEdit and Pe, but can be written to in nano.

I would be interested to know, if you ran ls -l in each of these 3 shares, if you see differences in the permissions, owner, and group columns, in the share that Tracker displays as empty compared to the other two.

Since I can reproduce an inability to write to a file I am trying to figure out that problem first. If one share displays as empty because the Tracker couldn't open the directory, then maybe the two symptoms have the same cause related to access rights.

[Jim906]

Any differences in server configuration between the 3 shares might also be relevant. In TrueNAS I think you can check this in the GUI by viewing Advanced Settings for each share.

[grexe]

The only difference was access rights, and I've fixed that now by fixing the ZFS dataset configuration in TrueNAS, resulting in Tracker being able to display the contents again.

However, I get the weird issue that filetypes are not detected correctly although the files are user read/writeable, but that's at least consistently wrong across all shares.

When forcing Tracker to open a file with "Proceed", I got a meeting with KDL. Update: this is a related issue but I need to reproduce yet.