Vamos primeiro ver o que acontece se um programa é iniciado a partir de um shell interativo (conectado a um terminal) sem & (e sem qualquer redirecionamento). Então vamos supor que você acabou de digitar foo:

O processo executando foo é criado.
O processo herda stdin, stdout e stderr do shell. Portanto, ele também está conectado ao mesmo terminal.
Se o shell receber um SIGHUP, ele também enviará um SIGHUP ao processo (o que normalmente faz com que o processo termine).
Caso contrário, o shell aguarda (está bloqueado) até que o processo termine.
Agora, vamos ver o que acontece se você colocar o processo em segundo plano, isto é, digitar foo &:

O processo executando foo é criado.
O processo herda stdout / stderr do shell (portanto, ele ainda grava no terminal).
O processo, em princípio, também herda stdin, mas assim que ele tenta ler de stdin, ele é interrompido.
Ele é colocado na lista de tarefas em segundo plano que o shell gerencia, o que significa especialmente:
Ele é listado com trabalhos e pode ser acessado usando% n (onde n é o número do trabalho).
Ele pode ser transformado em um trabalho em primeiro plano usando fg, nesse caso, continua como se você não tivesse usado & nele (e se ele foi parado devido a tentar ler a partir da entrada padrão, agora pode continuar a ler a partir do terminal ).
Se o shell recebeu um SIGHUP, ele também envia um SIGHUP para o processo. Dependendo do shell e possivelmente das opções definidas para o shell, ao finalizar o shell, ele também enviará um SIGHUP ao processo.
Agora disown remove o job da lista de jobs do shell, então todos os subpontos acima não se aplicam mais (incluindo o processo que está sendo enviado um SIGHUP pelo shell). No entanto, observe que ele ainda está conectado ao terminal, portanto, se o terminal for destruído (o que pode acontecer se for um pty, como aqueles criados pelo xterm ou ssh, e o programa de controle for finalizado, fechando o xterm ou encerrando o SSH conexão), o programa falhará assim que tentar ler a entrada padrão ou gravar na saída padrão.

O que o nohup faz, por outro lado, é separar efetivamente o processo do terminal:

Fecha a entrada padrão (o programa não será capaz de ler qualquer entrada, mesmo que seja executado em primeiro plano. Ele não será interrompido, mas receberá um código de erro ou EOF).
Ele redireciona a saída padrão e o erro padrão para o arquivo nohup.out, portanto, o programa não falhará para gravar na saída padrão se o terminal falhar, portanto, o que quer que o processo grava, não será perdido.
Isso impede que o processo receba um SIGHUP (assim, o nome).
Note que o nohup não remove o processo do controle do job do shell e também não o coloca em segundo plano (mas como um job nohup de primeiro plano é mais ou menos inútil, você geralmente o coloca em segundo plano usando &). Por exemplo, ao contrário do disown, o shell ainda lhe dirá quando a tarefa nohup foi concluída (a menos que o shell seja finalizado antes, é claro).

Então, para resumir:

& coloca o trabalho em segundo plano, isto é, bloqueia a tentativa de ler a entrada e faz com que o shell não espere pela sua conclusão.
disown remove o processo do controle de tarefa do shell, mas ainda o deixa conectado ao terminal. Um dos resultados é que o shell não envia um SIGHUP. Obviamente, ele só pode ser aplicado a tarefas em segundo plano, porque você não pode inseri-lo quando um trabalho em primeiro plano está em execução.
o nohup desconecta o processo do terminal, redireciona sua saída para nohup.out e protege-o do SIGHUP. Um dos efeitos (o nome) é que o processo não receberá nenhum SIGHUP enviado. É completamente independente do controle do trabalho e pode, em princípio, ser usado também para trabalhos em primeiro plano (embora isso não seja muito útil).