Hello Karl-Philip,

On Fri, Jul 15, 2016 at 01:44:48PM +0200, Karl-Philipp Richter wrote:
> So, I found http://aetey.se/files/pages/CodaInstHowto.html and ran the
> `.bin` installer. I'm able to see `/coda/richtercloud.de` now after

Nice!

> `sudo codaclient start` and `clog [user]@richtercloud.de` (which gives a
> token according to `ctokens`). However listing files in the
> `/coda/richtercloud.de` fails with `Input/output error`. I attached
> Aetey `venus.log` in which I don't see any suspicious entries.

I happen to see some.

> I verified that I'm using the Aetey binaries and deactivated the
> `coda-client` `systemd` unit in order to avoid any confusing. I'm
> loading the `coda` kernel module with `modprobe` after login to the
> display manager before all other actions.

Good.

> 
> [ W(13) : 0000 : 12:39:40 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:41 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:41 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:42 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:44 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:48 ] fsobj::Fetch: bytes mismatch (0, 2048)

I guess this is where the trouble is seen (it looks also
like the mailer has mangled these lines into one?)

Would you describe your setup once again?

- how many computers are involved
- which one has the hostname "richtercloud.de"
- which one is running the Coda client you are testing with
- whether you followed the advice on
  http://codawiki.cse.chalmers.se/Setting_up_a_server_to_work_from_behind_a_NAT.html

Note that a more or less robust test order would be:

- a separate server host
- a separate client host
- only a single server ip number involved, not across NAT
  (this can be a local ip-number now, but not for the later steps)
- DNS service which delivers the server computer's ip number
  when asked for what it believes to be its hostname
- both server and client start after the computers got their network
  connections, server first, client afterwards
- does this work? if yes then continue:

- follow the steps from the wiki (above) to ensure service availability
  from outside the apparently present NAT
- test with the client computer located outside the NAT
- does this work? if yes then continue:

- try to talk to the service from inside the NAT (still from
  a separate clent computer)
- does this work? if yes then continue:

- try to talk to the server from the same computer

When all of this works you may wish to explore disconnected
operation. Otherwise there are a way too many variables at play.

How long down this sequence do you manage to come?

Note, for NAT operation you can _not_ have "richtercloud.de" resolving
to a local ip number, neither for the server, nor for the client.
This must be the ip number corresponding to your external connection. Note
also that the server must be restarted every time your external connection
gets a different ip number.

Regards,
Rune