Is there a cleaner way of error handling in a series of system calls?

The following function makes a series of system calls to enlarge a mapped file buffer:

func (file *File) Ensure(more int) (err error) {
	if file.Append+more <= cap(file.Buf) {
		return
	}

	// there is not enough room
	if err = syscall.Munmap(file.Buf); err != nil {
		return
	}
	if _, err = file.Fh.Seek(0, os.SEEK_END); err != nil {
		return
	}
	if _, err = file.Fh.Write(make([]byte, file.Growth)); err != nil {
		return
	}
	if err = file.Fh.Sync(); err != nil {
		return
	}
	if file.Buf, err = syscall.Mmap(int(file.Fh.Fd()), 0, cap(file.Buf)+file.Growth, syscall.PROT_READ|syscall.PROT_WRITE, syscall.MAP_SHARED); err != nil {
		return
	}
	return
}

5 system calls are made in 5 lines and there are 11 lines of error handling code. Is there a cleaner way to do this?

It depends on your definition of cleanness. Some people think that handling an error where it occurs, in contrast to exceptions, is clean. Notice how you have in every of the error paths a clean point in code where other than default action (returning the error) can be taken. It can be an attempt to recover (where aplicable), it can ammend the error with more details, for example human readable tag about which of the five calls failed. Which is actually a good idea when one realizes that is easy to get some equivalent of, say EPERM or EINVAL from definitely more than one syscall.

Another observation is: How it is supposed to eliminate (if that would be hypothetically perceived as cleaner) the error detecting (if err != nil) and on-error action (return in this case)?

In your example, it is less obvious that the error-checking pattern is a good one. Comparing it with JVM and similar languages, an exception would be thrown by each of these calls and that pattern would require far fewer lines and a lot less fuss.

However (and it's a big 'however'), in other cases you might need to handle each error case differently from the others. In the Go style, this is easy. In the exception style, it's not; instead a lot of try-catch blocks would be needed and the amount of ceremony needed would be inverted.

So my conclusion is that I find the Go pattern a little of chore, but I appreciate there are times that it's a Good Thing and that makes up for the chore. I also find myself using panic a lot in startup code so I don't need any recovery from things that are essentially unrecoverable.

As a final observation, the functional programming pundits (e.g. in Scala) like the so-called Either pattern where a function returns either a result or an error; this is in preference to using exceptions. It's the same pattern as Go's really.