<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Hi all<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have a problem which is doing my head in.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We are running Gluster 3.6.3 with the in-built NFS server, across 8 servers. We share our volume out with SMB, AFP and Gluster’s NFS server.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In most cases, NFS works fine. Everything is visible and accessible from the terminal. But from Finder on our Macs, we are having a consistent problem.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Firstly, we are mounting the share from the command line:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>$ mount –t nfs –o rw,intr,nolock,tcp 10.0.19.31:/glusvol ./glusvol<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We then open Finder and traverse to the folder in question (about 7 levels deep). I see about 20-30 items, but I know there are 100+ items in there. This is the case on multiple folders. If I open a terminal, go to that folder, and create a new empty file, the folder refreshes in Finder and I can see everything. However, dismount and remount and everything is gone again (although sometimes it displays all files for a few seconds before most of them disappear). I’ve repeated this on three different Macs of varying origin and OS version.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve started Wireshark on my Mac and monitored what is happening. It appears that there is an initial NFS READDIR Call to the NFS server with cookie set to 0. The READDIR Reply contains the filename of every file in the folder. Then there is another READDIR call with cookie set to 4096, which happens to be the last cookie listed in the previous reply. Curiously, the reply to this call lists all the files that I *<b>cannot</b>* see in Finder. But doesn’t include the ones I can see. Then there are a whole lot of LOOKUP Calls while it looks at all the files that I *<b>can</b>* see. Then it stops at the 24<sup>th</sup> file, the last file I can see in Finder. It then issues another READDIR Call with a Cookie of 680. The Reply is “NFS3ERR_BAD_COOKIE”. Looking through the previous replies, the only time that cookie was issued was in the FIRST reply. And again, the file in question with that cookie number is the LAST file that I can see in Finder.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Surely, Finder cannot be THIS broken? I can see all files in that folder fine when I mount via AFS or SMB but not via NFS. But it all works fine from Terminal. We’re experimenting with updating Gluster to 3.7.8 and moving to NFS Ganesha in the hope that moving to NFSv4 fixes it, but does anyone have any idea what’s happening? I’m happy to send the .pcapng file to someone if it’s helpful. I also have a .pcapng of when we create a file in the folder and Finder refreshes to show everything in there. The only interesting thing that I noticed in that file is that the cookie number at the end of the READDIR is much larger than anything I was seeing in the failed listings (17179869176). I tried forcing 32-bit inode sizes in Gluster NFS options (the closest thing I could find to NFS’s native 32-bit cookie size restriction) with no joy, just in case that was part of it, which wouldn’t make sense but tried anyway and no difference.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks in advance.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Brett<o:p></o:p></p></div></body></html>