MacOS creates these .DS_Store files. On a NFS share these are created whenever a MacOS user accesses that specific folder. The .DS_Store files are created with these rights: -rwx------ 1 4294967294 4294967294 12292 Jul 18 17:59 .DS_Store Now if I try to list that folder from Dolphin, when the share is opened via the address bar like: nfs://192.168.1.1/some/share/ThatFolder Dolphin just says "Access denied to .DS_Store" and the loading of the folder never ends. Also, if I am listing and accessing files from the same share and where are no .DS_Store files it works (nfs://192.168.1.1/some/share/AnotherFolder). If I mount that folder as root to some place like /media/tmp, Dolphin can list the files correctly. Reproducible: Always Steps to Reproduce: 1. Create a NFS share somewhere 2. Access it from MacOS with it's builtin file manager 3. Observe the .DS_Store file being created with only the owner heaving access to it 4. Try to list the files in that folder from Dolphin as another user from Linux Actual Results: Folder never gots listed Expected Results: I expect the unaccessible .DS_Store file to be ignored and not listed, but all the files I have access to to be listed.
Thanks for the report, but I'm unable to test this because I neither have a Mac nor any other NFS shares here.
Resetting assignee to default as per bug #305719
Just create by hand a .DS_Store file set it to the following rights and put it on a NFS share: -rwx------ 1 4294967294 4294967294 12292 Jul 18 17:59 .DS_Store
Is this still reproducible in more recent versions? If yes, I think it's very unlikely that this is a Dolphin bug. It might be an issue in kdelibs or a kioslave.
No response -> I guess it works now.
I know much time passed, but I had not to use NFS lately and I forgot about this bug. Sorry for not replying. This is still reproducing on KDE 4.11.00. If it is not Dolphin related, please advice a proper place to report the bug. Thank you.
Thanks for the reply. I don't know what the right product for the bug is. I'll move it to KIO and hope that the people working on KIO have a better idea in case that's incorrect.
Is this still reproducible in 4.14? I can't reproduce it.
I've made some changes to the NFS ioslave recently, including with the handling of unreadable files or symlinks which in some cases would cause an entire directory listing to fail. Hopefully the problem is fixed, please reopen the bug if it is still happening.