Ask a Question

[WORKAROUND] SFTP server service fails to auto-start

0 votes
by (140 points)
edited by

After updating to v.2.5.3, the SFTP server service fails to automatically start upon restarting the machine. I was not experiencing this issue with previous versions of the server.

Setting the actions for 1st, 2nd, and subsequent failures to Restart (on the Recovery tab of the service property dialog window) does not make any difference.

Is anyone else experiencing this?

Additional info:
* OS: Windows 10 x64 Edu
* Server version: 2.5.3 x64
* Service set to run under a domain user account (i.e., not the local SYSTEM account)
* Connection allowed only from selected IPv4 addresses

Applies to: Buru SFTP Server

1 Answer

0 votes
by (2.0k points)

Hi,

when you try to start the server service manually, does it work as expected? What is the latest version that worked?

Thanks

Kind Regards

by (140 points)
edited by
Yes -- once I start the service manually (either via services.msc or the SFTP server web console), it keeps running. Only the auto-start is broken.

The last version that worked fine was 2.4.0 (I have not used any intermediate version between this one and 2.5.3).
by (2.0k points)
Hi,

I tried several times but unfortunately I wasn't able to replicate the issue. Please try enabling the logging (see https://www.rebex.net/buru-sftp-server/doc/configuration#logging) - if nothing shows up then there might be something in the Windows event log.
by (140 points)
edited by
Thank you for the tips. Windows Event Viewer contained no record for "Rebex Buru SFTP Server". After enabling the SFTP server log (verbose level) and restarting the machine, all I've got is a couple of lines as follows:

    2022-03-14 09:25:57.057 +01:00 [Information] Buru SFTP Server version 2.5.3 (component version 6.0.8056.0)
    2022-03-14 09:25:57.166 +01:00 [Debug] SSH encryption algs: [<REMOVED>]
    2022-03-14 09:25:57.170 +01:00 [Debug] SSH host key algs: [<REMOVED>]
    2022-03-14 09:25:57.170 +01:00 [Debug] SSH kex algs: [<REMOVED>]
    2022-03-14 09:25:57.171 +01:00 [Debug] SSH mac algs: [<REMOVED>]
    2022-03-14 09:25:57.173 +01:00 [Debug] Importing key(s) from <REMOVED>
    2022-03-14 09:25:57.270 +01:00 [Debug] Key "<REMOVED> (256-bit ecdsa-sha2-nistp256)" at <REMOVED> was added.
    2022-03-14 09:25:57.308 +01:00 [Debug] Key "<REMOVED> (256-bit ssh-ed25519)" at <REMOVED> was added.
    2022-03-14 09:25:57.321 +01:00 [Debug] Key "<REMOVED> (2048-bit ssh-rsa)" at <REMOVED> was added.
    2022-03-14 09:25:57.321 +01:00 [Information] Using key <REMOVED> (256-bit ecdsa-sha2-nistp256) from <REMOVED>.
    2022-03-14 09:25:57.339 +01:00 [Information] Using key <REMOVED> (256-bit ssh-ed25519) from <REMOVED>.
    2022-03-14 09:25:57.339 +01:00 [Information] Using key <REMOVED> (2048-bit ssh-rsa) from <REMOVED>.

The respective service, however, was not running. Once I started the service manually, the following lines were added to the server log:

    2022-03-14 09:29:13.449 +01:00 [Information] Buru SFTP Server version 2.5.3 (component version 6.0.8056.0)
    2022-03-14 09:29:13.608 +01:00 [Debug] SSH encryption algs: [<REMOVED>]
    2022-03-14 09:29:13.613 +01:00 [Debug] SSH host key algs: [<REMOVED>]
    2022-03-14 09:29:13.614 +01:00 [Debug] SSH kex algs: [<REMOVED>]
    2022-03-14 09:29:13.614 +01:00 [Debug] SSH mac algs: [<REMOVED>]
    2022-03-14 09:29:13.618 +01:00 [Debug] Importing key(s) from <REMOVED>
    2022-03-14 09:29:13.755 +01:00 [Debug] Key "<REMOVED> (256-bit ecdsa-sha2-nistp256)" at <REMOVED> was added.
    2022-03-14 09:29:13.795 +01:00 [Debug] Key "<REMOVED> (256-bit ssh-ed25519)" at <REMOVED> was added.
    2022-03-14 09:29:13.806 +01:00 [Debug] Key "<REMOVED> (2048-bit ssh-rsa)" at <REMOVED> was added.
    2022-03-14 09:29:13.807 +01:00 [Information] Using key <REMOVED> (256-bit ecdsa-sha2-nistp256) from <REMOVED>.
    2022-03-14 09:29:13.824 +01:00 [Information] Using key <REMOVED> (256-bit ssh-ed25519) from <REMOVED>.
    2022-03-14 09:29:13.824 +01:00 [Information] Using key <REMOVED> (2048-bit ssh-rsa) from <REMOVED>.
    2022-03-14 09:29:13.857 +01:00 [Information] Server will listen for Sftp requests on <REMOVED>.
    2022-03-14 09:29:13.882 +01:00 [Debug] IP Filter - Allow "<REMOVED>"
    2022-03-14 09:29:13.883 +01:00 [Debug] IP Filter - Allow "<REMOVED>"
    2022-03-14 09:29:13.883 +01:00 [Debug] IP Filter - Deny "0.0.0.0-255.255.255.255"
    2022-03-14 09:29:13.898 +01:00 [Information] Starting server.
    2022-03-14 09:29:13.901 +01:00 [Information] Listening for connections at <REMOVED>.
    2022-03-14 09:29:13.901 +01:00 [Information] Server started.

In other words, the auto-start process only proceeds to loading the keys, and then (before "[Information] Server will listen for Sftp requests on ...") it stops.

Probably irrelevant but for completeness' sake: I am using AVG Business in which two TCP/UDP "allow" rules (in/out) are defined for the SFTP server application.

Feel free to ask for more information if needed.
by (2.0k points)
This is most peculiar. Do you by any chance use server name in "ipAddress" field in bindings section?
by (140 points)
Yes, you are correct. The server is bound to the machine's FQDN, port different from the default 22. Only SFTP is allowed (i.e., not SCP).
by (2.0k points)
Ok, it looks like for some reason it times out on DNS resolution for the given hostname. We'll try to add some compensation. In the meantime, can you either try using IP address instead of hostname, or use Delayed start for the service (which might fix the issue)?
by (140 points)
I quickly tested both (separately) and both helped. I will keep delayed startup selected in the service Properties dialog until the issue is fixed.

Thank you for your assistance.
by (2.0k points)
I'm glad it helped. The fix should be present in the next release. Thank you for providing the details!
...