manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Swapna Vuppala <swapna.kollip...@gmail.com>
Subject Re: Problem crawling windows share
Date Tue, 13 Dec 2011 05:45:56 GMT
Thanks Karl for getting this far.

I understand that the chances of jCIFS working with this particular server
are very less. We'll leave it here for now and I'll let you know if I have
any more details on the server.

Thanks and Regards,
Swapna.

On Tue, Dec 13, 2011 at 7:24 AM, Karl Wright <daddywri@gmail.com> wrote:

> His response:
>
> "Actually from looking at the capture again, the successful operations
> in it were ultimately performed by a session that used Kerberos. But
> there are two other successful NTLM authentications that use the
> Anonymous credential. It so happens that neither of these went on to
> do anything successful. Meaning your capture does not contain a
> successful operation using NTLM and thus there is nothing to compare
> JCIFS too. It could be that the environment actually does not support
> NTLM properly. There are a lot of errors and oddities in the non-JCIFS
> communications with numerous login failures, disabled signatures,
> access denied conditions and unsupported versions of Windows (Windows
> Server 2002 SP2 build 2600). The environment is not optimal.
>
> To continue I would need proper comparison captures. Clearly the
> NtlmPasswordAuthentication("","","") does not work. But
> NtlmPasswordAuthentication.ANONYMOUS obviously does work to some
> degree but there's something else wrong with the session setup
> request. That something could be the fact that the hostname used is
> actually l-carx01.global.arup.com and not lon-data-arx.global.arup.com
> and then the tree connect goes on to mount
> //lon-data-arx.global.arup.com/stg-jobs$ so clearly there is some
> hostname discontinuity going on as well."
>
> I think this is pretty much self explanatory.  Whatever it is that you
> are trying to talk to seems to be one truly crazy machine, certainly
> not really Windows, and it is almost an accident that it works with
> Windows at all.  I think this is rapidly reaching the point of
> diminishing returns in getting jCIFS to work with it.
>
> Karl
>
>
> On Mon, Dec 12, 2011 at 4:24 AM, Karl Wright <daddywri@gmail.com> wrote:
> > I forwarded this research again to Mr. Allen for further suggestions.
>  Thanks!
> >
> > Karl
> >
> > On Mon, Dec 12, 2011 at 1:58 AM, Swapna Vuppala
> > <swapna.kollipara@gmail.com> wrote:
> >> Hi Karl,
> >>
> >> I tried modifying the test code as you suggested.
> >>
> >> When I tried with empty credentials
> >>
> >> NtlmPasswordAuthentication pa = new
> NtlmPasswordAuthentication("","","");
> >> SmbFile smbconnection = new SmbFile("smb://" +
> >> "lon-data-arx.global.arup.com" + "/" + "stg-jobs$",pa);
> >>
> >> I got the same exception as before
> >>
> >> Exception in thread "main" jcifs.smb.SmbAuthException: Logon failure:
> >> unknown us
> >>
> >> er name or bad password.
> >>         at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:546)
> >>         at jcifs.smb.SmbTransport.send(SmbTransport.java:663)
> >>
> >>         at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:390)
> >>         at jcifs.smb.SmbSession.send(SmbSession.java:218)
> >>         at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
> >>         at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)
> >>
> >> ......
> >>
> >> When I tried with NtlmPasswordAuthentication.ANONYMOUS
> >>
> >> SmbFile smbconnection = new SmbFile("smb://" +
> >> "lon-data-arx.global.arup.com" + "/" +
> >> "stg-jobs$",NtlmPasswordAuthentication.ANONYMOUS);
> >>
> >> I got a different exception
> >>
> >> Exception in thread "main" jcifs.smb.SmbException: Incorrect function.
> >>         at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:563)
> >>         at jcifs.smb.SmbTransport.send(SmbTransport.java:663)
> >>         at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:316)
> >>
> >>         at jcifs.smb.SmbSession.send(SmbSession.java:218)
> >>         at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
> >>         at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)
> >> .....
> >>
> >> Thanks and Regards,
> >> Swapna.
> >> On Fri, Dec 9, 2011 at 11:46 PM, Karl Wright <daddywri@gmail.com>
> wrote:
> >>>
> >>> Michael Allen's response to your capture:
> >>>
> >>> "It looks like the non-JCIFS communication is successful because the
> >>> anonymous credential is used.
> >>>
> >>> Note that there is still no sign of DFS going on anywhere. Actually
> >>> JCIFS tries to do a referral for the DFS root and gets an error of
> >>> STATUS_FS_DRIVER_REQUIRED so it looks like DFS may not even be setup
> >>> at all in the target environment. At least not domain based DFS.
> >>>
> >>> So if you want to emulate Windows behavior, I guess you need to retry
> >>> the operation with credential NtlmPasswordAuthentication.ANONYMOUS (or
> >>> all empty strings should work too I think like ";:")."
> >>>
> >>> In other words, the issue is that the server in question does not
> >>> actually recognize the credentials given at all, and gives an error.
> >>> But while Windows then retries with no credentials whatsoever, nothing
> >>> in JCIFS does that retry.
> >>>
> >>> You can confirm that this is what is happening by using an empty user
> >>> name, password, and domain in the JCIFS test code you wrote to obtain
> >>> the captures.  If, then, the test code works against that server, I'll
> >>> create a ticket for downgrading to ANONYMOUS whenever there is an
> >>> authentication error in the JCIFS connector.
> >>>
> >>> Thanks,
> >>> Karl
> >>>
> >>> On Wed, Dec 7, 2011 at 6:41 AM, Karl Wright <daddywri@gmail.com>
> wrote:
> >>> > The next step is to obtain two packet captures using WireShark.
>  These
> >>> > should both be done from the machine that is not joined to the
> domain.
> >>> >  The first capture should be the interaction that takes place when
> you
> >>> > try to go to the foreign directory, and you supply the credentials,
> >>> > and then you list the folders.  The second capture will require you
> to
> >>> > do the same using JCIFS.  For that capture, you will need jcifs.jar
> >>> > and a simple example class that provides jcifs with credentials and
> >>> > tries to list the directory.  A simple class should be enough to do
> >>> > this, including code such as:
> >>> >
> >>> > import jcifs.smb.*;
> >>> >
> >>> > NtlmPasswordAuthentication pa = new
> >>> > NtlmPasswordAuthentication(domain,username,password);
> >>> > SmbFile smbconnection = new SmbFile("smb://" + server + "/" +
> share,pa);
> >>> > SmbFile[] files = smbconnection.listFiles();
> >>> >
> >>> > for (int i = 0 ; i < files.length ; i++)
> >>> > {
> >>> >        System.out.println(file.toString());
> >>> > }
> >>> >
> >>> > I suggest you put together your test class first and make sure it
> >>> > works, and then go after the captures.
> >>> >
> >>> > Let me know how it goes.
> >>> >
> >>> > Karl
> >>> >
> >>> > On Wed, Dec 7, 2011 at 6:10 AM, Swapna Vuppala
> >>> > <swapna.kollipara@gmail.com> wrote:
> >>> >> Hi Karl,
> >>> >>
> >>> >> Thanks for the detailed reply.
> >>> >>
> >>> >> As per your suggestion, I tried connecting to the problematic server
> >>> >> via
> >>> >> windows using a machine that is not in the domain. On supplying
the
> >>> >> credentials via windows, I could connect to the server, although
it
> did
> >>> >> not
> >>> >> list any folders. But when I tried accessing the folder of my
> interest
> >>> >> via
> >>> >> \\server\folder$, I could see all the sub folders. All this is
when
> I
> >>> >> connected via windows from a machine that's not joined to the
> domain.
> >>> >>
> >>> >> The behavior is same when I connect to the server via windows from
a
> >>> >> machine
> >>> >> that's joined to the domain.
> >>> >>
> >>> >> So I assume this means that through both Kerberos and NTLM, I see
> the
> >>> >> same
> >>> >> behavior. Whereas ManifoldCF throws an exception when trying to
> define
> >>> >> the
> >>> >> repository connection.
> >>> >>
> >>> >> Please advise me on what I should be doing next to resolve this.
> >>> >>
> >>> >> Thanks and Regards,
> >>> >> Swapna.
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Tue, Dec 6, 2011 at 12:55 PM, Karl Wright <daddywri@gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> About your capture - Michael Allen says the following:
> >>> >>>
> >>> >>> "Actually this has nothing to do with DFS. JCIFS does not get
to
> the
> >>> >>> point where it does DFS anything. The capture shows a vanilla
> >>> >>> STATUS_LOGON_FAILURE when GLOBAL\swapna.vuppala tries to auth
with
> >>> >>> l-carx01.global.arup.com. So the possible causes for this are
1)
> the
> >>> >>> account name is not valid 2) the supplied password is incorrect
3)
> >>> >>> some security policy is deliberately blocking that user or
> particular
> >>> >>> type of auth or 4) some server configuration is incompatible
with
> >>> >>> JCIFS. I only mention this last option because I noticed the
target
> >>> >>> server has security signatures disabled. That's strange. If
they're
> >>> >>> messing around with things like that, who knows what their
clients
> are
> >>> >>> expected to do.
> >>> >>>
> >>> >>> Try a Windows client that uses NTLM instead of Kerberos. Meaning
> try a
> >>> >>> machine that is not joined to the domain so that when you try
to
> >>> >>> access the target it asks you for credentials at which point
you
> can
> >>> >>> test with GLOBAL\swapna.vuppala. Then it will use NTLM and
you can
> >>> >>> actually compare captures. If the operator doesn't have a laptop
or
> >>> >>> something not joined to the domain, it might be sufficient
to log
> into
> >>> >>> a workstation using machine credentials and not domain credentials.
> >>> >>>
> >>> >>> Also when testing JCIFS you should use a simple stand-alone
program
> >>> >>> like examples/ListFiles.java."
> >>> >>>
> >>> >>> In other words:
> >>> >>> (a) Since JCIFS does not use Kerberos for authentication, you
need
> to
> >>> >>> try to log into the recalcitrant server via Windows without
using
> >>> >>> Kerberos to be able to do a side-by-side comparison.  Michael
has
> some
> >>> >>> ways of doing that, above.
> >>> >>> (b) You may find that it doesn't work, in which case JCIFS
is not
> >>> >>> going to work either.
> >>> >>> (c) If it *does* work, then try to generate your side-by-side
> >>> >>> comparisons using a simpler example rather than ManifoldCF
en toto;
> >>> >>> you can see how at jcifs.samba.org, or I can help you further.
> >>> >>>
> >>> >>> He also mentions that there is some bizarreness on the response
> that
> >>> >>> indicates that the server is configured in a way that he's
never
> seen
> >>> >>> before.  And believe me, Michael has seen a *lot* of strange
> >>> >>> configurations...
> >>> >>>
> >>> >>> Hope this helps.
> >>> >>> Karl
> >>> >>>
> >>> >>> On Mon, Nov 28, 2011 at 4:12 AM, Karl Wright <daddywri@gmail.com>
> >>> >>> wrote:
> >>> >>> > That should read "properties.xml", not "properties.ini".
 It
> looks
> >>> >>> > like this page needs updating.
> >>> >>> >
> >>> >>> > The debug property in the XML form is:
> >>> >>> >
> >>> >>> > <property name="org.apache.manifoldcf.connectors" value="DEBUG"/>
> >>> >>> >
> >>> >>> > I don't think it will provide you with any additional
information
> >>> >>> > that
> >>> >>> > is useful for debugging your authentication issue, however,
if
> that
> >>> >>> > is
> >>> >>> > why you are looking at it.  There may be some jcifs.jar
debugging
> >>> >>> > switches that might be of more help, but in the end I
suspect you
> >>> >>> > will
> >>> >>> > need a packet capture of both a successful connection
(via
> Windows)
> >>> >>> > and an unsuccessful one (via MCF).  The guy you will need
to talk
> >>> >>> > with
> >>> >>> > after that is the jcifs author Michael Allen; I can give
you his
> >>> >>> > email
> >>> >>> > address if you get that far.
> >>> >>> >
> >>> >>> > Karl
> >>> >>> >
> >>> >>> >
> >>> >>> > On Mon, Nov 28, 2011 at 1:30 AM, Swapna Vuppala
> >>> >>> > <swapna.kollipara@gmail.com> wrote:
> >>> >>> >> Hi Karl,
> >>> >>> >>
> >>> >>> >> I was planning to debug jCIFS repository connection
using
> WireShark
> >>> >>> >> and
> >>> >>> >> I
> >>> >>> >> came across this
> >>> >>> >> https://cwiki.apache.org/CONNECTORS/debugging-connections.html
> >>> >>> >> Here, I see something as add
> >>> >>> >> "org.apache.manifoldcf.connectors=DEBUG"
> >>> >>> >> to the
> >>> >>> >> properties.ini file. Is it the properties.xml file
that is being
> >>> >>> >> referred
> >>> >>> >> here ? If not, where do I find properties.ini file
?
> >>> >>> >>
> >>> >>> >> Thanks and Regards,
> >>> >>> >> Swapna.
> >>> >>> >>
> >>> >>> >> On Thu, Nov 17, 2011 at 1:31 PM, Karl Wright <
> daddywri@gmail.com>
> >>> >>> >> wrote:
> >>> >>> >>>
> >>> >>> >>> See
> http://jcifs.samba.org/src/docs/api/overview-summary.html#scp.
> >>> >>> >>> The properties jcifs.smb.lmCompatibility and
> >>> >>> >>> jcifs.smb.client.useExtendedSecurity are the ones
you may want
> to
> >>> >>> >>> change.  These two properties go together so certain
> combinations
> >>> >>> >>> make
> >>> >>> >>> sense and others don't, so there's really only
combinations you
> >>> >>> >>> need
> >>> >>> >>> but I'll need to look at what they are and get
back to you
> later
> >>> >>> >>> today.
> >>> >>> >>>
> >>> >>> >>> As far as setting the switches are concerned,
if you are using
> the
> >>> >>> >>> Quick Start you do this trivially by:
> >>> >>> >>>
> >>> >>> >>> <java> -Dxxx -Dyyy -jar start.jar
> >>> >>> >>>
> >>> >>> >>> If you are using the multi-process configuration,
that is what
> the
> >>> >>> >>> "defines" directory is for; you only need to create
files in
> that
> >>> >>> >>> directory with the names "jcifs.smb.lmCompatibility"
and
> >>> >>> >>> "jcifs.smb.client.useExtendedSecurity" containing
the values
> you
> >>> >>> >>> want
> >>> >>> >>> to set.
> >>> >>> >>>
> >>> >>> >>> Karl
> >>> >>> >>>
> >>> >>> >>>
> >>> >>> >>> On Thu, Nov 17, 2011 at 1:11 AM, Swapna Vuppala
> >>> >>> >>> <swapna.kollipara@gmail.com> wrote:
> >>> >>> >>> > Hi Karl,
> >>> >>> >>> >
> >>> >>> >>> > Am able to access the folders on the problem
server through
> >>> >>> >>> > windows
> >>> >>> >>> > explorer, (\\server3\Folder1). I tried couple
of things with
> the
> >>> >>> >>> > credentials
> >>> >>> >>> > form, changing username, domain etc.. but
I keep getting the
> >>> >>> >>> > same
> >>> >>> >>> > error
> >>> >>> >>> > "Couldn't connect to server: Logon failure:
unknown user
> name or
> >>> >>> >>> > bad
> >>> >>> >>> > password"
> >>> >>> >>> >
> >>> >>> >>> > Can you tell me more about the -D switch
you were talking of
> ?
> >>> >>> >>> >
> >>> >>> >>> > Thanks and Regards,
> >>> >>> >>> > Swapna.
> >>> >>> >>> >
> >>> >>> >>> > On Tue, Nov 15, 2011 at 12:40 PM, Karl Wright
> >>> >>> >>> > <daddywri@gmail.com>
> >>> >>> >>> > wrote:
> >>> >>> >>> >>
> >>> >>> >>> >> Glad you chased it down this far.
> >>> >>> >>> >>
> >>> >>> >>> >> First thing to try is whether you can
get into the problem
> >>> >>> >>> >> server
> >>> >>> >>> >> using Windows Explorer.  Obviously ManifoldCF
is not going
> to
> >>> >>> >>> >> be
> >>> >>> >>> >> able
> >>> >>> >>> >> to do it if Windows can't.  If you *can*
get in, then just
> >>> >>> >>> >> playing
> >>> >>> >>> >> with the form of the credentials in the
MCF connection
> might do
> >>> >>> >>> >> the
> >>> >>> >>> >> trick.  Some Windows or net appliance
servers are picky
> about
> >>> >>> >>> >> this.
> >>> >>> >>> >> Try various things like leaving the domain
blank and
> specifying
> >>> >>> >>> >> the
> >>> >>> >>> >> user as "abc@domain.com", for instance.
There's also a
> >>> >>> >>> >> different
> >>> >>> >>> >> NTLM
> >>> >>> >>> >> mode you can operation jcifs in that
some servers may be
> >>> >>> >>> >> configured
> >>> >>> >>> >> to
> >>> >>> >>> >> require; this would need you to set a
-D switch on the
> command
> >>> >>> >>> >> line
> >>> >>> >>> >> to
> >>> >>> >>> >> enable.
> >>> >>> >>> >>
> >>> >>> >>> >> Karl
> >>> >>> >>> >>
> >>> >>> >>> >> On Tue, Nov 15, 2011 at 12:10 AM, Swapna
Vuppala
> >>> >>> >>> >> <swapna.kollipara@gmail.com> wrote:
> >>> >>> >>> >> > Hi Karl,
> >>> >>> >>> >> >
> >>> >>> >>> >> > Thanks for the input. It looks like
my problem is related
> to
> >>> >>> >>> >> > the
> >>> >>> >>> >> > second
> >>> >>> >>> >> > one
> >>> >>> >>> >> > that you specified. One of the directories
in the path am
> >>> >>> >>> >> > trying
> >>> >>> >>> >> > to
> >>> >>> >>> >> > index is
> >>> >>> >>> >> > actually redirecting to a different
server. And when I
> >>> >>> >>> >> > specify
> >>> >>> >>> >> > this
> >>> >>> >>> >> > new
> >>> >>> >>> >> > server in defining the repository
connection, with my
> >>> >>> >>> >> > credentials,
> >>> >>> >>> >> > the
> >>> >>> >>> >> > connection fails with the message:
 "Couldn't connect to
> >>> >>> >>> >> > server:
> >>> >>> >>> >> > Logon
> >>> >>> >>> >> > failure: unknown user name or bad
password"
> >>> >>> >>> >> >
> >>> >>> >>> >> > I'll look into why am not able to
connect to this server.
> >>> >>> >>> >> >
> >>> >>> >>> >> > Thanks and Regards,
> >>> >>> >>> >> > Swapna.
> >>> >>> >>> >> >
> >>> >>> >>> >> > On Mon, Nov 14, 2011 at 4:56 PM,
Karl Wright
> >>> >>> >>> >> > <daddywri@gmail.com>
> >>> >>> >>> >> > wrote:
> >>> >>> >>> >> >>
> >>> >>> >>> >> >> There's two kinds of problem
you might be having.  The
> first
> >>> >>> >>> >> >> is
> >>> >>> >>> >> >> intermittent, and the second
is not intermittent but
> would
> >>> >>> >>> >> >> have
> >>> >>> >>> >> >> something to do with specific
directories.
> >>> >>> >>> >> >>
> >>> >>> >>> >> >> Intermittent problems might
include a domain controller
> that
> >>> >>> >>> >> >> is
> >>> >>> >>> >> >> not
> >>> >>> >>> >> >> always accessible.  In such
cases, the crawl will proceed
> >>> >>> >>> >> >> but
> >>> >>> >>> >> >> will
> >>> >>> >>> >> >> tend to fail unpredictably.
 On the other hand, if you
> have
> >>> >>> >>> >> >> a
> >>> >>> >>> >> >> directory that is handled by
a DFS redirection, it is
> >>> >>> >>> >> >> possible
> >>> >>> >>> >> >> that
> >>> >>> >>> >> >> the redirection is indicating
a new server (lets call it
> >>> >>> >>> >> >> server3)
> >>> >>> >>> >> >> which may not like the precise
form of your login
> >>> >>> >>> >> >> credentials.
> >>> >>> >>> >> >>  Can
> >>> >>> >>> >> >> you determine which scenario
you are seeing?
> >>> >>> >>> >> >>
> >>> >>> >>> >> >> Karl
> >>> >>> >>> >> >>
> >>> >>> >>> >> >> On Mon, Nov 14, 2011 at 3:11
AM, Swapna Vuppala
> >>> >>> >>> >> >> <swapna.kollipara@gmail.com>
wrote:
> >>> >>> >>> >> >> > Hi,
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> > I have been using windows
share repository connection
> to
> >>> >>> >>> >> >> > crawl
> >>> >>> >>> >> >> > and
> >>> >>> >>> >> >> > get
> >>> >>> >>> >> >> > data
> >>> >>> >>> >> >> > from a particular server
(server 1). Its working
> perfectly
> >>> >>> >>> >> >> > fine.
> >>> >>> >>> >> >> > However, am
> >>> >>> >>> >> >> > having trouble when I try
with data from another server
> >>> >>> >>> >> >> > (server
> >>> >>> >>> >> >> > 2).
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> > When I define a repository
connection of type windows
> >>> >>> >>> >> >> > share
> >>> >>> >>> >> >> > and
> >>> >>> >>> >> >> > specify
> >>> >>> >>> >> >> > the
> >>> >>> >>> >> >> > server name (server 2)
with my credentials, the
> connection
> >>> >>> >>> >> >> > status
> >>> >>> >>> >> >> > shows
> >>> >>> >>> >> >> > "Connection working". But
when I run a job to use this
> >>> >>> >>> >> >> > repository
> >>> >>> >>> >> >> > connection
> >>> >>> >>> >> >> > and index data from a location
on this server 2, I keep
> >>> >>> >>> >> >> > getting
> >>> >>> >>> >> >> > the
> >>> >>> >>> >> >> > exception below:
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> > JCIFS: Possibly transient
exception detected on
> attempt 3
> >>> >>> >>> >> >> > while
> >>> >>> >>> >> >> > checking
> >>> >>> >>> >> >> > if
> >>> >>> >>> >> >> > file exists: Logon failure:
unknown user name or bad
> >>> >>> >>> >> >> > password.
> >>> >>> >>> >> >> > jcifs.smb.SmbAuthException:
Logon failure: unknown user
> >>> >>> >>> >> >> > name
> >>> >>> >>> >> >> > or
> >>> >>> >>> >> >> > bad
> >>> >>> >>> >> >> > password.
> >>> >>> >>> >> >> >     at
> >>> >>> >>> >> >> >
> jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:544)
> >>> >>> >>> >> >> >     at
> jcifs.smb.SmbTransport.send(SmbTransport.java:661)
> >>> >>> >>> >> >> >     at
> >>> >>> >>> >> >> > jcifs.smb.SmbSession.sessionSetup(SmbSession.java:390)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbSession.send(SmbSession.java:218)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbFile.doConnect(SmbFile.java:911)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbFile.connect(SmbFile.java:954)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbFile.connect0(SmbFile.java:880)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbFile.queryPath(SmbFile.java:1335)
> >>> >>> >>> >> >> >     at jcifs.smb.SmbFile.exists(SmbFile.java:1417)
> >>> >>> >>> >> >> >     at
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector.fileExists(SharedDriveConnector.java:2064)
> >>> >>> >>> >> >> >     at
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector.getDocumentVersions(SharedDriveConnector.java:521)
> >>> >>> >>> >> >> >     at
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> >
> org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:318)
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> > Am able to access this
location from windows explorer.
> >>> >>> >>> >> >> > What
> >>> >>> >>> >> >> > else
> >>> >>> >>> >> >> > should
> >>> >>> >>> >> >> > I be
> >>> >>> >>> >> >> > checking or what could
be the reasons/factors causing
> this
> >>> >>> >>> >> >> > to
> >>> >>> >>> >> >> > fail
> >>> >>> >>> >> >> > ?
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >> > Thanks and Regards,
> >>> >>> >>> >> >> > Swapna.
> >>> >>> >>> >> >> >
> >>> >>> >>> >> >
> >>> >>> >>> >> >
> >>> >>> >>> >
> >>> >>> >>> >
> >>> >>> >>
> >>> >>> >>
> >>> >>
> >>> >>
> >>
> >>
>

Mime
View raw message