Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

com.hierynomus.mssmb2.SMBApiException: STATUS_OTHER (0xffffffff): Cannot resolve path #419

Closed
cliviu opened this issue Dec 17, 2018 · 11 comments

Comments

@cliviu
Copy link

cliviu commented Dec 17, 2018

Hi, I have the following exception:
2018-12-14 16:38:04,408|DFSPathResolver |INFO |Starting DFS resolution for \host1.com\Share\Resource
2018-12-14 16:38:04,408|ProxySocketFactory |DEBUG|Connecting to \host1.com\Share:445
2018-12-14 16:38:04,424|Connection |INFO |Closed connection to \host1.com\Share
2018-12-14 16:38:04,424|SMBClient |DEBUG|Connection to << \host1.com\Share:445 >> closed
|ERROR|FileCopy:STATUS_OTHER (0xffffffff): Cannot resolve path \host1.com\Share\Resource
com.hierynomus.mssmb2.SMBApiException: STATUS_OTHER (0xffffffff): Cannot resolve path \host1.com\Share\Resource
at com.hierynomus.smbj.share.DiskShare.resolveAndCreateFile(DiskShare.java:81)
at com.hierynomus.smbj.share.DiskShare.open(DiskShare.java:66)
at com.hierynomus.smbj.share.DiskShare.exists(DiskShare.java:187)
at com.hierynomus.smbj.share.DiskShare.folderExists(DiskShare.java:183)
...
at java.lang.Thread.run(Thread.java:748)
Caused by: com.hierynomus.msdfsc.DFSException: java.net.UnknownHostException: \host1.com\Share
at com.hierynomus.smbj.paths.DFSPathResolver.sendDfsReferralRequest(DFSPathResolver.java:397)
at com.hierynomus.smbj.paths.DFSPathResolver.step9(DFSPathResolver.java:306)
at com.hierynomus.smbj.paths.DFSPathResolver.step2(DFSPathResolver.java:140)
at com.hierynomus.smbj.paths.DFSPathResolver.step1(DFSPathResolver.java:120)
at com.hierynomus.smbj.paths.DFSPathResolver.resolve(DFSPathResolver.java:107)
at com.hierynomus.smbj.paths.DFSPathResolver.resolve(DFSPathResolver.java:95)
at com.hierynomus.smbj.share.DiskShare.resolveAndCreateFile(DiskShare.java:77)
... 9 more

in DfsPathResolver, Line 395, there is a TODO:
connection = oldConnection.getClient().connect(hostName); // TODO

Does it ring any bells ?

The strange thing is that two minutes before, the same resolution was successful.
2018-12-14 16:36:04,533|DFSPathResolver |INFO |Starting DFS resolution for \host1.com\Share\Resource
2018-12-14 16:36:04,533|DFSPathResolver |INFO |DFS resolved\host1.com\Share\Resource -> \host2.com\Share$\Test...

Thanks,
Liviu

@cliviu
Copy link
Author

cliviu commented Dec 17, 2018

Apparently, the name resolution works always if there is a gap of about 10 minutes between calls.

@hierynomus
Copy link
Owner

The cached referral has expired in your case (see: DFSPathResolver#140). Will dig into that.

@cliviu
Copy link
Author

cliviu commented Dec 18, 2018

Thanks !!

@Disablez
Copy link
Contributor

Same problem here.

@vjorge
Copy link

vjorge commented Jun 24, 2022

Hi, facing the same issue.
Anyone can share a workaround?
I have an ISO file that needs to be kept open for random read, and after +-15 minutes it throws the exact same error above.
Using the latest code.
Many thanks,

@vjorge
Copy link

vjorge commented Jun 24, 2022

Hi I found what is causing the issue:
The function sendDfsReferralRequest, is expecting the hostName as a string with the server name, but instead the functions
stepX and passing the hostname with the format " \\host1.com\Share"

Then in function sendDfsReferralRequest it triggers the condition:

if (!hostName.equals(session.getConnection().getRemoteHostname())) {

Because the provided hostName is a UNC path not the host FQDN thus causing the error:

Caused by: com.hierynomus.msdfsc.DFSException: java.net.UnknownHostException: \host1.com\Share

I have not found what is causing the hostName to be passed with the format " \host1.com\Share"

@hierynomus can you please help with this?

private ReferralResult sendDfsReferralRequest(DfsRequestType type, String hostName, Session session, DFSPath path) throws DFSException {
        // The client MUST initiate a server session with the SMB server, as specified in [MS-CIFS] section 3.4.4.7,
        // by passing HostName and UserCredentials as input parameters and receiving an opaque ClientGenericContext,
        // as specified in [MS-CIFS] section 3.4.
        // The client MUST search for an existing Session and TreeConnect to any share on the server identified by
        // ServerName for the user identified by UserCredentials. If no Session and TreeConnect are found, the client
        // MUST establish a new Session and TreeConnect to IPC$ on the target server as described in section 3.2.4.2
        // using the supplied ServerName and UserCredentials
        Session dfsSession = session;
        if (!hostName.equals(session.getConnection().getRemoteHostname())) {
            AuthenticationContext auth = session.getAuthenticationContext();
            Connection oldConnection = session.getConnection();
            Connection connection;
            try {
                connection = oldConnection.getClient().connect(hostName); // TODO
            } catch (IOException e) {
                throw new DFSException(e);
            }
            dfsSession = connection.authenticate(auth);
        }

        try {
            Share dfsShare = dfsSession.connectShare("IPC$"); // explicitly not closed as we want to re-use the cached Share for multiple requests
            return getReferral(type, dfsShare, path);
        } catch (Buffer.BufferException | IOException e) {
            throw new DFSException(e);
        }
    }

@vjorge
Copy link

vjorge commented Jun 24, 2022

Found the issue:

In function step9,
ReferralResult result = sendDfsReferralRequest(DfsRequestType.LINK, rootReferralCacheEntry.getTargetHint().getTargetPath(), session, state.path);

the call:

rootReferralCacheEntry.getTargetHint().getTargetPath()

returns a UNC path, not a FQDN hostname .

Adding a simple validation and translation fixed the issue.

        String target = rootReferralCacheEntry.getTargetHint().getTargetPath();
        if (target.startsWith("\\")) {
        	target = SmbPath.parse(target).getHostname();
        }

I believe the correct way to fix it is to create a field in the ReferalCacheEntry that also allows to return the Hostname instead of the

@SuppressWarnings("PMD.UnusedFormalParameter")
private <T> T step9(Session session, ResolveState<T> state, ReferralCache.ReferralCacheEntry lookup) throws DFSException {
    logger.trace("DFS[9]: {}", state);
    DFSPath rootPath = new DFSPath(state.path.getPathComponents().subList(0, 2));
    ReferralCache.ReferralCacheEntry rootReferralCacheEntry = referralCache.lookup(rootPath);
    if (rootReferralCacheEntry == null) {
        logger.debug("Could not find referral cache entry for {}", rootPath);
        referralCache.clear(state.path);
        return step1(session, state);
    }

    String target = rootReferralCacheEntry.getTargetHint().getTargetPath();
    if (target.startsWith("\\")) {
    	target = SmbPath.parse(target).getHostname();
    }
    
   // ReferralResult result = sendDfsReferralRequest(DfsRequestType.LINK, rootReferralCacheEntry.getTargetHint().getTargetPath(), session, state.path);
    ReferralResult result = sendDfsReferralRequest(DfsRequestType.LINK, target, session, state.path);
    if (!NtStatus.isSuccess(result.status)) {
        return step14(session, state, result);
    }

    if (result.referralCacheEntry.isRoot()) {
        return step3(session, state, result.referralCacheEntry);
    }

    return step4(session, state, result.referralCacheEntry);
}

@vjorge
Copy link

vjorge commented Jun 24, 2022

Seems that found the issue:

The problem is with function step9 in :

ReferralResult result = sendDfsReferralRequest(DfsRequestType.LINK, rootReferralCacheEntry.getTargetHint().getTargetPath(), session, state.path);

The call rootReferralCacheEntry.getTargetHint().getTargetPath() return a UNCPath not a FQDN hostname, but the sendDfsReferralRequest expects a FQDN Hostname, thus causing the connection to fail.

Bellow is the changed function that works, but I believe the correct way to fix it is to have a field named hostName in ReferralCache that returns the server hostname, and use it instead of the getTargetPath().

private <T> T step9(Session session, ResolveState<T> state, ReferralCache.ReferralCacheEntry lookup) throws DFSException {
     logger.trace("DFS[9]: {}", state);
     DFSPath rootPath = new DFSPath(state.path.getPathComponents().subList(0, 2));
     ReferralCache.ReferralCacheEntry rootReferralCacheEntry = referralCache.lookup(rootPath);
     if (rootReferralCacheEntry == null) {
         logger.debug("Could not find referral cache entry for {}", rootPath);
         referralCache.clear(state.path);
         return step1(session, state);
     }
     
     /*
      * Alterado por mim, porque existe um bug ou falha no codigo que passa o unc em vez do hostname
      */
     String target = rootReferralCacheEntry.getTargetHint().getTargetPath();
     if (target.startsWith("\\")) {
     	target = SmbPath.parse(target).getHostname();
     }
     
    // ReferralResult result = sendDfsReferralRequest(DfsRequestType.LINK, rootReferralCacheEntry.getTargetHint().getTargetPath(), session, state.path);
     ReferralResult result = sendDfsReferralRequest(DfsRequestType.LINK, target, session, state.path);
     if (!NtStatus.isSuccess(result.status)) {
         return step14(session, state, result);
     }

     if (result.referralCacheEntry.isRoot()) {
         return step3(session, state, result.referralCacheEntry);
     }

     return step4(session, state, result.referralCacheEntry);
 }

@hierynomus
Copy link
Owner

Can you test with the fix in #722? I've changed the implementation slightly.

@vjorge
Copy link

vjorge commented Jun 28, 2022

Hi hierynomus,
Many thanks for your update.
Seems that now its fixed ;) It works great.
Thank very much.
Vitor

@hierynomus
Copy link
Owner

Merged #722

hierynomus added a commit that referenced this issue Jul 3, 2023
* Ignore VSCode

* Add NtStatus.STATUS_UNSUCCESSFUL

* Add NtStatus.STATUS_INSUFF_SERVER_RESOURCES (#611)

* Add NtStatus.STATUS_IO_REPARSE_TAG_NOT_HANDLED (#514)

* Update gradle build

* Update release plugin

* Release version: 0.11.0

* Fix signing task dependency

* Release version: 0.11.1

* Use BCSecurityProvider by default for SMB3 compatibility (Fixes #638)

* Ensure DFS Path Referral times out after transactTimeout (Fixes #578)

* Only add DFSPathResolver if both client and server support DFS (#640)

* Only add DFSPathResolver if both client and server support DFS

* Fix indentation problems

* Fix incorrectly reformatted javadoc

* Format using java formatter

* One more indentation fix

* Upgrade Bouncy Castle to 1.68 to fix vulnerability report (#641)

* address issue #604 - stop closing the dfs share connection immediately. (#609)

* stop closing the dfs share connection immediately.

* Add explanatory comment

Co-authored-by: Jeroen van Erp <[email protected]>

* Add support for unregistering server from serverlist (Fixes #644) (#647)

* Add support for unregistering server from serverlist (Fixes #644)

* Fix indentation

* Reducing logging for smb3 (#650)

For each smb3 packet there's an info log message which produces a tremendous amount of output.
I would suggest to reduce log level to debug (or trace; similarly as in one of the other packet reciever classes).

* Consolidate SMBv1 error messages

* Upgrade BouncyCastle to 1.69

* Release version: 0.11.2

* Ensure artifact is signed

* Release version: 0.11.3

* Fix #665: Allow JCE KDF to work (#666)

* Fix #665: Allow JCE KDF to work

* Add header

* Add KDF unit test

* Use correct maxPayloadSize for encrypted packets (Fixes #668) (#683)

* Read fileId as long (#693)

* Read fileId of FileIdBothDirectoryInformation into a long
* Read fileId of FileIdFullDirectoryInformation into a long

* File the issue that nested folder creation throw NAME EXIST error. (#685)

* File the issue that nested folder creation throw NAME EXIST error.

* formatting

* Updated build status badges (#684)

- Added GitHub badge for Build SMBJ
- Corrected Codacy badge link
- Removed bintray badge link
- Removed Travis CI badge and configuration
- Removed Java profiler link
- Removed CircleCI configuration
- Removed unused github-ci configuration

* Use AceSize field when reading ACEs (#696)

Fixes issue seen in the wild where unnecessary padding at the end of an ACE
confused Smbj (but not Windows).

* Ensure that enough bytes are cached from InputStream to get a correct bytesLeft count for SMB2Write (fixes #669)

* GzipOutputStream integration test

* Ensure that enough bytes are cached from InputStream to get a correct bytesLeft count for SMB2Write

Co-authored-by: Stanislav Kardashov <[email protected]>
Co-authored-by: Jeroen van Erp <[email protected]>

* Add GH workflow for publishing

* Update dependencies and build file

* Rename test class to *Spec

* Release version: 0.11.5

* Use the hostname part of the TargetHint for DFS step 9 (fixes \#419) (#722)

* Slightly reduce the locking in Connection.send and DirectTcpTransport (fixes \#732)

* Fixed indentation

* Converting bytes written to long (Fixes #740)

Signed-off-by: Jeroen van Erp <[email protected]>

* Upgrading gradle to 8.0.2

Signed-off-by: Jeroen van Erp <[email protected]>

* Add Implementation manifest attributes (Fixes #743)

* Revert accidental comment of integration docker tasks

* Do not send SMB2EncryptionCapabilities NegotiationContext is !isEncry… (#752)

* Do not send SMB2EncryptionCapabilities NegotiationContext is !isEncryptionSupported (Fixes #747)

* Add test for SMB2EncryptionCapabilities

* Add preliminary changelog for new release

* Ensure we call flip() on Buffer to avoid Java8 problems (Fixes #705)

Signed-off-by: Jeroen van Erp <[email protected]>

* Ensure path is set for rmdir to prevent accidents (Fixes #756)

Signed-off-by: Jeroen van Erp <[email protected]>

* Add support for reading / writing NIO ByteBuffers (#759)

* Add support for reading / writing NIO ByteBuffers

Currently one can transfer data using streams or array, but it would be
great to have the opportunity to use NIO buffers.

This adds two new method to the File class that accept a NIO ByteBuffer.

* Implemented ByteBuffer write using ByteChunkProvider

Signed-off-by: Jeroen van Erp <[email protected]>

---------

Signed-off-by: Jeroen van Erp <[email protected]>
Co-authored-by: Christoph Läubrich <[email protected]>
Co-authored-by: Jeroen van Erp <[email protected]>

* Fix some sonatype warnings

* resolve conflict with master

* Ignore non-semver tags for release workflow

* Small warning cleanup

Signed-off-by: Jeroen van Erp <[email protected]>

* Setup ConnectionContext and AuthenticationContext for NTLM improvements

Signed-off-by: Jeroen van Erp <[email protected]>

* Refactor TargetInfo/AvPairs

* Added null check and rename field

* Refactor NtlmFunctions

* Change hierarchy of Ntlm messages

Signed-off-by: Jeroen van Erp <[email protected]>

* Next step of NTLM refactor

* NtlmNegotiate sends Domain/Workstation/Version fields

* Filter negotiateflags and use clientTargetInfo

* Rework keys in NtlmAuthenticator

Signed-off-by: Jeroen van Erp <[email protected]>

* Change to structure of NtlmAuthenticate

Signed-off-by: Jeroen van Erp <[email protected]>

* Added last changes

Required to put withIntegrity = false still, due to missing mechListMIC

Signed-off-by: Jeroen van Erp <[email protected]>

---------

Signed-off-by: Jeroen van Erp <[email protected]>
Co-authored-by: Nicholas DiPiazza <[email protected]>
Co-authored-by: ndimitry <[email protected]>
Co-authored-by: Patrick Boyd <[email protected]>
Co-authored-by: Hannes <[email protected]>
Co-authored-by: pyzhou <[email protected]>
Co-authored-by: exceptionfactory <[email protected]>
Co-authored-by: Chris Pacejo <[email protected]>
Co-authored-by: Stanislav Kardashov <[email protected]>
Co-authored-by: Stanislav Kardashov <[email protected]>
Co-authored-by: Christoph Läubrich <[email protected]>
Co-authored-by: Christoph Läubrich <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants