kbfs is repeatedly trying to connect without success

When I typed cd /keybase/public/dtiersch the terminal doesn't respond anymore (entering only /keybase/public worked; ls showed only the folder dtiersch which is probably right) since keybase is trying to connect to the server in the background, which I could see in the log files:

2016-04-21T23:40:09.389503 ▶ [DEBU kbfs connection.go:243] 168 (CONN MDServerRemote 0e0b0b61) Connection: dialing transport
2016-04-21T23:40:09.711403 ▶ [DEBU kbfs connection.go:256] 169 MDServerRemote: OnConnect called with a new connection
2016-04-21T23:40:09.711457 ▶ [DEBU kbfs mdserver_remote.go:119] 16a MDServerRemote: resetAuth called
2016-04-21T23:40:09.812788 ▶ [DEBU kbfs mdserver_remote.go:119] 16b MDServerRemote: received challenge
2016-04-21T23:40:10.263532 ▶ [DEBU kbfs crypto_client.go:139] 16c Signed 445-byte message: err=Login required: KBFS Authentication
2016-04-21T23:40:10.263608 ▶ [WARN kbfs mdserver_remote.go:119] 16d MDServerRemote: error signing authentication token: Login required: KBFS Authentication
2016-04-21T23:40:10.263651 ▶ [WARN kbfs connection.go:258] 16e (CONN MDServerRemote 0e0b0b61) Connection: error calling OnConnect handler: libkb.LoginRequiredError{Context:"KBFS Authentication"}
2016-04-21T23:40:10.263695 ▶ [WARN kbfs connection.go:411] 16f MDServerRemote: connection error: "Login required: KBFS Authentication"; retrying in 1m3.563546944s

repeatedly for some minutes until I cancelled to send the logs.

Before I installed updated the client, rebooted the machine, and then ran run_keybase:

Launching keybase service...
Mounting /keybase...
Launching Keybase GUI...
Success!
                                                  ▄▄▄▄█▀
╭───────────────────────╮          ▄▄          ▄▄▄█▄▄▀
│                       │         ███▄▄▄▄▄▄▄▄▄▄███▄██
│  Encrypt everything!  │       ▄▄▄████▄▄▄███████████
│                       ├────  ▄▄▄▄▄████▄█████████████
╰───────────────────────╯      ███▄█▄█████████████████▄▄
                                ▀▄███████▄▀ ███████████▄▄
                                  ▄▄▄▄███    ███████████▄▄
                                 ▄████████   ██████████████
                                ▄███▄█████▄▄  ▀▄████████████
                               ███████▄▄██▄█▄▄ █████████████
                              ▄▄█████████████▄▄ ████████████
                           ▄██▄▄████▄▄▄█▄▄█████ ████████████
                                ███▄▄▄▄▄███████▄▄█████████▄▀
                                ▄█████▄▄█████████████▄█████
                                █▄██████████▄▄▄▄▄▄▄███████
                              ▄▄▄▄▄██▄▄█████▄████████████
                            ▀▀▀▀▀▀▀▀▄▄▄▄██▄▀ ▀▀▄▄▄▄▄▄▀▀▀
                                  ▀▀▀▀▀▀▀▀▀

which worked perfectly fine

Version Information:

Platform Information:
    OS:        linux
    Runtime:   go1.6
    Arch:      amd64

Client:
    version:   1.0.15-20160421160809+aff0140

my log id: ffe9c91154496a586756af1c

Start with the reported cd /keybase/public/dtiersch reproduction and inspect the connection flow in connection.go, mdserver_remote.go, and crypto_client.go. Compare the login-required error and retry behavior in the supplied logs; done means the failed connection is handled without leaving the filesystem command unresponsive or retrying indefinitely.