Cygwin does not see Windows share as folder - no “d” attribute?

Question

I migrated this question from StackOverflow as it really fell outside the scope of programming questions they generally prefer, so hopefully I'll find a more suitable audience here...

I've installed Cygwin 1.7 on a Windows Server 2008/64 box in support of an automated file transfer setup. While the basic install is generally working as expected, I have one curious problem that must be solved.

After logging into the server from a Windows command prompt via ssh, I perform an "ls -l" against the UNC path of the server, eg:

$ ls //servername

That returns the list of shares on that server; however, some of the shares are listed without the "d" (directory) attribute set - Cygwin is seeing them only as regular files. As a result, attempts to cd to the share path fail with "Not a directory" errors. However, ls against that share name works.

In some instances, the name of the share and its underlying folder each contain a space, so that was my first suspect, but there are other shares on the same machine with no spaces in the share or folder name that exhibit the same behavior.

Here is a representative albeit condensed listing of the ls command, with actual share/server/owner names replaced with ShareNameN, servername, or UserName as appropriate. UserName is that of the ssh user session.

$ ls -l //servername
total 33636078380235
drwxrwxrwx+ 1 Administrators Domain Users                 0 Nov 26 10:35 ShareName1
-rw-r--r--  1 UserName       Domain Users 18193726281664696 Apr 22  2009 ShareName2
-rw-r--r--  1 UserName       Domain users 18189229448232975 Aug  4  1909 Share Name3

$ ls -l //servername/ShareName2
//servername/ShareName2

$ cd //servername/ShareName2
-bash: cd: //servername/ShareName2: Not a directory

$ ls //servername/"Share Name3"
//servername/Share Name3

$ cd //servername/"Share Name3"
-bash: cd: //servername/Share Name3: Not a directory

I've tried some other permutations of the quoted UNC pathname, verified the permissions on the share and the underlying folder, but so far, no luck. The user is authenticating via an actual password, not via certificates.

I'm likely missing something obvious, so if someone can see the error of my ways, I'd be most appreciative!

EDIT: I have just observed an interesting pattern that may be a factor in this problem

I just observed that those shares indicating a creation date other than the last few months - the ones in which the time of day is listed rather than the year - also do not have the directory attribute set through the "ls" command. All shares listing a time of day do have the directory attribute set, and work normally through the cd command...

Answer 1

I have determined the cause of this problem, thanks to good ol' ProcMon. As the shares were being enumerated, ProcMon was revealing an "ACCESS DENIED" on the attempt to open/query the shares that were failing, but "SUCCESS" on those that worked.

The account used to ssh into the subject server did not have read permissions to the shares in question. Granting the account read permissions to the share(s) resolved the subject behavior.