Transfem/transmasc/etc. não necessariamente indicam gênero


Uma explicação detalhada originalmente publicada no Reddit

Eu acho que isto não é novidade para ninguém que me acompanha em colorid.es, então resolvi publicar isto no Reddit, onde tem mais gente nova e/ou sem contato com discussões intracomunidade. Link para a publicação no r/naobinarie.


Oi pessoal, nesses últimos anos eu andei vendo muitas confusões e presunções sobre os termos transfeminine e transmasculine, as quais também podem ser aplicadas a outros termos, como transneutre, transandrógine e transxenine. Questões como "como alguém bigênero homem/mulher pode ser transmasculine" ou "como alguém pode ser transfeminine sem se expressar de tal jeito".

O que quero fornecer aqui são detalhes sobre estes termos, para facilitar o entendimento das nuances que não aparecem quando alguém explica esses termos de forma resumida.

Definições dos termos originais (transfeminine e transmasculine)


As definições originais de transfeminine e transmasculine especificam que:

  • São pessoas que podem ou não ser mulheres/homens respectivamente;
  • Que foram impostas os gêneros homem e mulher ao nascer, respectivamente;
  • E que estão próximas ao outro lado do "espectro binário":
    • ou por comportamentos ou corpos associados com feminilidade ou masculinidade, respectivamente;
    • ou por identificação de gênero, como no caso de demimulheres ou demi-homens, por exemplo.


Com o tempo, esta definição foi mudando, muitas vezes para ser mais vaga em questão do que conta como identificação com e/ou transição para feminilidade/masculinidade.

Aqui está uma definição de Pride-Flags de 2015 que diz que pessoas transfemininas "se identificam mais com feminilidade do que com masculinidade", aqui está uma definição de transmasculine da LGBTQIA+ Wiki, que começa falando de gênero mas depois de alguns parágrafos aponta que o termo nem sempre é uma identidade de gênero e pode também apontar transição "masculinizadora" com hormônios/cirurgias. A Nonbinary Wiki coloca que pessoas transfemininas "almejam se apresentar de forma feminina, se identificam mais como mulheres do que como homens ou querem transicionar para serem mais femininas", e que pessoas transmasculinas "possuem gêneros masculinos e/ou se expressam de forma masculina". The Transgender Dictionary tem páginas detalhadas para transmasculine e transfeminine, ambas apontando que são termos amplos mesmo que foquem mais em identidade de gênero, expressão de gênero e transição.

Algo que nunca se perdeu foi a questão destes termos poderem denotar expressões de gênero ou outras identificações com feminilidade e masculinidade que não precisam ser atadas a gênero.

(Uma questão que também surge atualmente é se imposição de gênero ao nascer importa para avaliar quem pode ser transfem/transmasc. Isto daria em um outro texto longo explicando as nuances de cada caso, especialmente quando experiências intersexo e/ou de pessoas não documentadas ao nascer são levadas em consideração, então não vou entrar nisto aqui.)

Expressão de gênero


Expressão de gênero não precisa denotar gênero. E isso também se aplica quando uma pessoa é não-binária (e/ou trans).

Há pessoas que se identificam como transfemininas, pessoas não-binárias femininas ou mesmo mulheres não-bináries porque gostam de se expressar de formas esterotipicamente relacionadas com mulheres (algo que geralmente é o que se coloca como feminilidade): maquiagem colorida mas não totalmente fora de padrão aceitável para mulheres, saias e vestidos, meia-calça, roupas de seções de "moda feminina", bolsas ao invés de mochilas, cores vivas, tratamento a/ela/a etc. Isto não é um problema, desde que não vire uma arma contra a autoidentificação alheia.

Mas uma homem também pode gostar de usar blush e sombra, de usar saias florais com camisas de cores vibrantes, de ser tratada por a/ela/a e assim por diante. Alguém assim pode dizer (se quiser) que sua expressão de gênero é feminina, e isto não anula que a pessoa é homem e/ou que a pessoa não tem um gênero relacionado com feminilidade ou mulheridade.

A mesma coisa se aplica a pessoas não-binárias. Ume mulher não-binárie e/ou uma pessoa transfeminina também pode se identificar mais com expressões de gênero neutras, andróginas ou masculinas, e usar os termos mencionados para denotar que seus gêneros são próximos ao gênero mulher e/ou que suas transições legais ou corporais são similares às comumente associadas com mulheres trans. A própria inconformidade de gênero em relação ao que se espera do gênero mulher pode (em alguns casos) informar a alienação que estas pessoas sentem caso pensem em si mesmes somente como mulheres.

Alinhamento de gênero


Este termo também parece ter se espalhado puramente com base em interpretação pessoal a partir das palavras em si (leia-se: 'vibes') ao invés do que realmente era pra ser: uma forma de pessoas não-binárias aproximarem que passam por questões relacionadas às de um determinado gênero independentemente de terem tal gênero ou não.

Basicamente: alinhamento de gênero é uma identificação opcional que pessoas não-binárias podem ter, e ela pode ser baseada em gênero e/ou expressão de gênero, mas também pode ser baseada em como a pessoa é lida socialmente em sua rotina, caso a pessoa considere isto relevante.

Alinhamento de gênero também não precisa ser binário. Ume demi-homem que achou que era agênero por uma década, que fez e faz parte de vários espaços agênero e que não se importa em ser viste como agênero pode dizer que é alinhade com a identidade agênero, por exemplo.

Na minha perspectiva, a abertura de termos como transfeminine, transmasculine, transneutre, transnule e etc. é mais coerente com um subtipo de alinhamentos de gênero (quando pensados de forma vaga, e não como substituição para "ser quase tal gênero" ou "se expressar como tal gênero") do que com identidades ou expressões de gênero.

Mas aí é uma perspectiva pessoal, outras pessoas podem preferir separar completamente os conceitos. Por exemplo: uma pessoa pode usar transmasculine como identidade de gênero por ter um gênero não-binário masculino e uma expressão de gênero masculina e dizer que tem alinhamento de gênero com o gênero mulher por sua história de vida e por como a maioria das pessoas em volta tratam esta pessoa transmasculina como mulher.

Então é ruim alguém dizer que seu gênero é transfem/transmasc/transangi/etc.?


Não. Assim como não é "ruim" alguém descrever seu gênero como enebê feminine, alinhade com neutralidade, lésbique ou punk: é só entender que não é porque algumas pessoas consideram que estes termos definem suas identidades de gênero que estes termos estão sempre ou primariamente definindo identidades de gênero.

Então pra quê servem estes termos?


Para comunidades poderem ser formadas a partir de determinadas experiências. Geralmente pessoas que usam estes termos sentem conforto de alguma forma em se encaixarem dentro de determinadas características associadas com gênero independentemente de outros aspectos de suas identidades.

Por exemplo, uma comunidade transneutra pode incluir:

  • Uma pessoa gênero-fluido chamada Ana Miguel de expressão de gênero variável que quer retirar seios por querer que seu corpo seja mais associado com neutralidade. Esta pessoa seria transneutra por sua transição física;
  • Uma pessoa gênero neutro que não vai realizar transição física mas que quer retificar seus documentos com um nome e um marcador de "sexo neutro" e que sempre se veste com roupas pretas por considerá-las neutras. Esta pessoa seria transneutra por sua identidade de gênero, expressão de gênero e transição legal;
  • Ume homem não-binárie que está confortável com termos como homem e cara e que se considera gay por sua atração por homens, mas que em geral quer ser viste de forma neutra e como alguém fora do binário de gênero e faz terapia hormonal com estrogênio e bloqueador de testosterona por conta disso. Esta pessoa seria transneutra por sua expressão de gênero e transição física;
  • Uma pessoa neutrois que gosta de usar vestidos ou leggings com estampas chamativas mesmo reconhecendo que sua expressão de gênero não seria considerada neutra, mas que tem euforia de gênero quando é reconhecida como fora do binário de gênero. Esta pessoa seria transneutra por sua identidade de gênero.

Nem todas as pessoas em tal comunidade vão se interessar em discussões sobre procedimentos cirúrgicos, sobre como expressar neutralidade ou sobre como descrever a experiência de ter um gênero neutro. No entanto, desde que ninguém esteja averse a tais discussões, o termo transneutre permite o agrupamento de pessoas que se sentem contempladas por ao menos um entre tais aspectos da transneutralidade.

A mesma coisa vale para os outros termos. Há pessoas transfemininas que consideram ter gêneros próximos de ser mulher e pessoas transfemininas que são tanto mulheres quanto homens mas que consideram transfeminilidade como um conceito útil para descrever seus processos de transição físicos, sociais e/ou legais. Há pessoas transxeninas por serem xenogênero e priorizarem tal aspecto de suas identidades socialmente e pessoas transxeninas que não são xenogênero mas que querem expressar sua não-binaridade por meio de roupas e modificações corporais que lhes deixarão com aparência que associam com a de alguma espécie não humana.

Portanto, tais termos não servem por si só para dizer se uma pessoa é ou não é mulher/homem e se portanto faz sentido usar termos associados a isso (como lésbique ou aquileane). Ume mulher não-binárie pode ser transmasculine, uma pessoa agênero pode ser transfeminina, uma pessoa bigênero mulher/homem pode ser transneutra.

Existem várias pessoas transmasculinas que são homens não-binários com tratamento o/ele/o que só compram roupas da "seção masculina", fazem terapia hormonal com testosterona e fizeram/estão na fila para fazer mastectomia e faloplastia. A questão não é que estas pessoas não existem ou estão erradas, e sim de que a transmasculinidade é mais ampla do que este molde estrito. A mesma coisa vale para outros termos na mesma linha.

Que termos existem?


É só unir um prefixo de modalidade de gênero (geralmente trans, mas também pode ser iso ou últer, por exemplo) com um sufixo ou uma combinação de sufixos denotando uma característica de gênero específica. Ou seja, pessoas podem ser transneufem, isoandróginas, ultermasculinas, absouterinas e assim por diante.

O termo multitransicional cobre quem usa mais de um termo com o prefixo trans neste contexto (como transmasculine + transneutre ou transouterine + transnule + transxenine).

Dito isso, aqui estão uns apontamentos menos óbvios:

  • As características andrina e ginina foram cunhadas para pessoas que querem especificar conexão com hombridade e mulheridade, respectivamente, sem referência obrigatória a masculinidade e feminilidade (características geralmente mais ligadas com normas ou expressões de gênero do que com os gêneros homem e mulher em si);
  • Os sufixos -solar e -floral denotam, respectivamente, uma mulheridade masculina e uma hombridade feminina;
  • Androginia deve ser abreviada como angi, não andro, já que andro significa homem (ex.: isoandrógine → isoangi);
  • Extrinidade é 'o equivalente não-binário' em relação a qualidades de gênero. Qualquer qualidade que não for 100% feminina ou 100% masculina pode ser chamada de extrina. Nenhuma descrição menciona o que acontece com características ligadas mais diretamente aos gêneros mulher e homem, mas, de qualquer forma, alguém pode se dizer transextrine ao invés de escolher entre transnule, transneutre, transandrógine, transouterine e assim por diante. Uma comunidade transextrina também acolheria pessoas dentro de todos os termos assim fora transfeminine e transmasculine;
  • Não tem problema usar os adjetivos aporine (referente a aporagênero) ou maverine (referente a maverique), mas outerine cobre características que não são relacionadas a homem, mulher, masculinidade, feminilidade, androginia, neutralidade, nulidade ou xeninidade;
  • Geralmente o que se usa para denotar ausência de características de gênero é o conceito de nulidade, como em transnule, mas também há quem prefira utilizar o termo ageneridade (ou outro similar) (que também pode cobrir outros sentidos associados especificamente com a identidade agênero).

Alinhamento de gênero e como essa terminologia se tornou inadequada


Uma postagem marcante na discussão sobre alinhamento de gênero definiu a ideia desta forma:

Por conta da forma que [identidades não-binárias] se cruzam com o binário de gênero, há vezes que é útil nos categorizarmos como pessoas com experiências comuns com homens ou com mulheres. Se existe uma sobreposição muito grande, como quando alguém é exclusivamente percebide como homem/mulher e então está sujeite a problemas sociais que afetam tais classes, pode haver valor em "nos alinharmos" com essas classes, para ter discussões significativas sobre como opressão funciona.

Há valor em poder dizer "sou negativamente afetade por esse conjunto específico de preconceitos de gênero, mesmo que eu não seja deste gênero".

Esse era o propósito inicial de termos como "alinhade com homem" e de "alinhade com mulher". Identificar sobreposições fortes em pressões externas e experiências, ou identificar sobreposições de identidade pessoal com as experiências de outro gênero.


Os exemplos dados foram de ume proxvir racializade poder ter uma narrativa similar a de um homem racializado quanto a racismo específico contra homens, e de ume ambonec com TEPT complexo viste como mulher poder ser sujeite a um monte de misoginia médica em relação à sua diagnose e ao seu tratamento da mesma forma que uma mulher cis seria.

Esta mesma postagem também fala de como esses termos foram cooptados para significar "basicamente binárie" ou até mesmo "basicamente cis", e sugere então termos novos para que pessoas não tenham que se associar com essas ideias.

Tais termos são lunariane ("alguém que tem similaridades em identidade ou experiência com mulheres"), solariane ("alguém que tem similaridades em identidade ou experiência com homens") e estelariane ("alguém que não possui alinhamento forte com o binário de gênero, ou que rejeita tal alinhamento").

Acho interessante que esta postagem fala de alinhamento quase que exclusivamente como uma questão de uma pessoa ser injustamente colocada na mesma categoria que um gênero binário e sofrer algum tipo de opressão por isso.

Não acho que todas as pessoas usavam alinhamento só por isso, também. Mesmo as pessoas que não usavam esse tipo de identidade por conta de opressão baseada em gênero ou para serem exorsexistas (apagando as identidades individuais de pessoas não-binárias para dizer "mas você na verdade é homem/mulher" sem dizer isso de forma explícita) às vezes queriam expressar conexão com algum gênero binário por conta de expressão de gênero, sentimento interno ou transição desejada, motivos pelos quais algumas pessoas também usam termos como homem/mulher não-binárie, transmasculine e transfeminine.

Eu não sei dizer se isso seria um problema para o propósito de descrever opressão por gênero. Eu diria que não. Em ambos os casos, alinhamento seria uma forma de uma pessoa não-binária dizer que tem algum tipo de experiência/sentimento/vivência em comum com alguém de algum gênero binário, caso queira sinalizar algo do tipo.

Mas, mesmo nos círculos com a melhor das intenções, isso deu errado.

Problema 1: Misturar alinhamento de gênero com definições/categorizações de identidades de gênero


Logo quando os termos estelariane, lunariane e solariane foram cunhados, pessoas já aparentemente não pegaram a ideia disso ser algo opcional e pessoal, e começaram a associar certas identidades com certos alinhamentos.

Postagens apareciam colocando zenina, juxera, demimulher, libramulher e mulher-fluxo como identidades lunarianas, por exemplo.

Algumas pessoas também começaram a cunhar termos e, ao invés de dizer que eram associados com tal gênero, diziam que eram alinhados com tal gênero.

Eu entendo que alguém que sente alguma similaridade com a identidade mulher pode se identificar como lunariane. Mas se o exemplo original de uma pessoa alinhada com o gênero mulher na postagem que cunhou lunariane é de ume ambonec, dizer que gêneros específicos são de alinhamentos específicos não pode acabar deixando pessoas que não possuem gêneros relacionados aos binários desconfortáveis demais para usar termos como lunariane ou solariane por conta da opressão que sofrem?

Isso também é presumir sobre as identidades/vivências das pessoas. E se alguém for demimulher, mas for uma pessoa transmasculina que só se identifica como parcialmente mulher por isso fazer parte do seu gênero e não vê isso como uma parte relevante da sua identidade a ponto de ser seu alinhamento? E se algume juxera achar mais relevante a confusão que as pessoas têm com seu gênero por conta de sua expressão genderfuck do que a proximidade do seu gênero com mulher?

Cunhar termos com base em alinhamentos não é um problema tão grande, porque se alguém se identificar com o resto do termo mas não se ver como alinhade com algo, é só não usar. Ainda assim, não vejo porque não seria melhor deixar o gênero só relacionado com algo, e então deixar pessoas decidirem seus próprios alinhamentos de gênero separadamente.

Pessoas também começaram a perguntar, em blogs de ajuda, por "gêneros alinhados com tal coisa". Sendo que, se alinhamento de gênero não é associado com gênero, qualquer identidade de gênero pode ter qualquer alinhamento. Ume ambonec pode ser lunariane, uma pessoa agênero pode ser solariana, ume zenina pode ser estelariane, etc. Eu entendo que provavelmente o que querem dizer é que querem saber mais sobre gêneros associados/parecidos com certo gênero, mas isso não ajuda pessoas cujas identidades de gênero não deixam seus alinhamentos "óbvios" a se sentirem seguras em compartilhar/ir atrás de comunidades para tal alinhamento.

Um exemplo de como isso é ruim: Ume maverique é viste como homem e participou de espaços para homens por um longo tempo, antes de se perceber não-binárie. Tal maverique não se sente confortável com pessoas presumindo que elu é homem, mas isso de qualquer forma acontece com frequência e afeta suas experiências de vida. Solariane poderia ser um rótulo confortável para elu, porém grande parte das coisas disponíveis para pessoas solarianas presume que a maioria delas é de algum gênero parecido com homem, ou que são parcialmente homens, ou que são homens parte do tempo. Alguém que está tentando se afastar da ideia de que "na verdade é homem" vai se sentir confortável adotando esse alinhamento de gênero?

Problema 2: Misturar alinhamento com gêneros binários com feminilidade/masculinidade


Como já falei em outro texto, feminilidade e masculinidade são termos usados de duas formas que, ainda que façam sentido com suas definições básicas, são bem distintas na prática:

  1. Ser uma pessoa feminina ou masculina significa se dizer ao menos "meio mulher" ou "meio homem", respectivamente;
  2. Ser uma pessoa feminina ou masculina significa aderir a arquétipos relacionados a estereótipos de gêneros binários.

O que acontece é que, muitas vezes, pessoas passaram a usar "alinhamento com feminilidade/masculinidade" ao invés de "alinhamento com mulher/homem". Talvez isso seja por acharem que, por exemplo, alinhamento com feminilidade seja uma forma mais abrangente de falar de alinhamentos relacionadas com ser mulher, ao invés de ser um alinhamento estrito com ser mulher.

Mas isso acaba alienando as pessoas que rejeitam a ideia de que feminilidade/masculinidade precisa ter a ver com estar perto de um gênero binário (1), e que são mais acostumadas com a ideia de que ser uma pessoa feminina/masculina tem só a ver com se identificar com certos arquétipos/estereótipos, independentemente do gênero (2).

Um exemplo: Imaginem ume femil - uma pessoa cujo gênero é mulher, mas com 0% de feminilidade e ao menos alguma identificação com masculinidade - que passou boa parte da vida se identificando como bofinho. Que sempre foi criticade por não ser feminine, e que enfrenta violência por ser viste como "mulher que se veste de homem". Essa pessoa tem um gênero relacionado com mulher, e passa por questões enfrentadas por mulheres binárias, então faz sentido dizer que possui um alinhamento de gênero com mulher. Mas será que alguém assim se identificaria com um alinhamento com feminilidade?

Esse exemplo pode ser fictício, mas a pessoa que cunhou femil e melle é melle e já falou que não consegue usar o sistema de alinhamento de gênero por conta das pessoas juntarem feminilidade com ser mulher e masculinidade com ser homem, ainda que seja uma pessoa que se vê como alguém que tem alinhamento com ser homem e com feminilidade, mas não com ser mulher ou com masculinidade.

Problema 3: A obrigação de alinhamento


Isso não é algo tão presente em círculos mais inclusivos, e nunca cheguei a ver isso na lusosfera, mas acho que é uma questão importante pra apontar, já que é relacionada com o assunto.

Para não ignorar a existência de pessoas não-binárias que se identificam com termos vistos como binários, e também não ignorar que pessoas que usam os termos vistos como binários não querem que tais termos sejam deturpados, é comum haverem definições como:

Lésbica: Uma mulher ou pessoa alinhada com o gênero mulher que sente atração somente por mulheres ou por pessoas alinhadas com o gênero mulher.


Eu não acho que essa definição é necessariamente problemática, porque pela maior parte ela está certa. E não acho que adicionar todas as exceções possíveis a definições é um processo muito útil, já que sempre vão haver mais delas.

Mas, tipo assim, já não tem um monte de casos lá em cima no texto sobre um monte de casos onde pessoas não são (completamente, sempre, etc.) mulheres e não se sentem/talvez não se sintam confortáveis se dizendo lunarianas/alinhadas com o gênero mulher?

Fora que, se é comum que pessoas relacionem pessoa alinhada com o gênero mulher com pessoa com identidade de gênero relacionada com ser mulher, isso não poderia causar problemas para lunarianes que são agênero, maveriques, ou de outras identidades que não possuem mulher no nome ou na definição?

Ou pior: Como pessoas vão se sentir confortáveis adotando ou mantendo essa identidade se, mesmo que sintam alguma conexão ou relação forte com ser mulher, não possuem identidade de gênero com mulher no nome ou na definição, e não se sentem confortáveis se dizendo lunarianes/alinhades com o gênero mulher por conta das questões listadas acima?

Os problemas que isso causa não são apenas teóricos: existem pessoas que se afastam de espaços para homens com atração por homens/mulheres com atração por mulheres por medo de invadir mesmo que se identifiquem com os termos usados, e existem pessoas tratadas como "invasoras" por não se identificarem com os termos de identidade e/ou alinhamento de gênero "certos" para que possam ser aceitas em tais espaços.

Existem sim termos como feminamórique e viramórique, mas muita gente gosta de ter um termo "que a maioria entende" como identidade, e as comunidades femínicas, mascúlicas, feminamóricas, viramóricas, dóricas e trízicas não são muitas nem grandes.

Problema 4: Falta de comunicação entre "desalinhades" e pessoas com alinhamentos não-tradicionais


Não é à toa que foquei muito mais em alinhamentos com homem e com mulher neste texto; são os alinhamentos mais discutidos e destacados.

Mas até mesmo estelariane foi um termo cunhado junto a lunariane e solariane. Se lunariane significa que a pessoa tem alinhamento com ser mulher, e solariane significa que a pessoa tem alinhamento com ser homem, estelariane aponta, pra mim, um alinhamento com não-binaridade.

Isso pode parecer desnecessário: pra quê ter um alinhamento com não-binaridade, se a pessoa já é não-binária?

Eu acredito que a intenção tenha sido de oferecer um termo que explicitamente diz "não, eu não me vejo como alguém próxime de um gênero binário, ou como alguém mais próxime de um gênero binário do que do outro". Que diz "não importa a minha identidade de gênero ou como as pessoas me veem, eu não me sinto confortável em dizer que tenho experiências em comum com um dos gêneros binários".

Que diz "não, eu não tenho um alinhamento binário". Então, é, um alinhamento com qualquer coisa que não seja binária.

Eu acredito que a ideia tenha sido que estes três termos fossem absolutos; ou você se identifica como alguém que tem algo em comum com algum gênero binário, ou não (seja por ter coisas em comum com ambos, seja por não não ter nada em comum com ambos, seja por rejeitar a ideia de ter algo em comum com um ou outro).

Mas, é, quando a comunidade gosta de termos e começa a usá-los, buracos começam a aparecer.

Surgiram alinhamentos que são combinações desses três termos; surgiram alinhamentos que são parcialmente cada um desses três termos; surgiu o termo singulariane para quem não tem alinhamento nenhum.

Muita gente também começou a ver estelariane como um alinhamento com neutralidade.

Mais tarde, também surgiu xênique, um termo para quem tem alinhamento com um ou mais xenogêneros. Também surgiram termos mais específicos para conceitos xenogênero específicos (como alinhamentos com luz, com animais, com cristais, etc).

Mas, o que importa aqui, é que parte da comunidade ignorou todo esse desenvolvimento, e agiu como se só houvessem pessoas alinhadas com mulheres, com homens, ou sem alinhamento.

Eu não acho que há algo de errado em falar que existem pessoas sem alinhamento de gênero. Porém, em muitos textos, era como se não ter alinhamento de gênero fosse sinônimo com não ter um alinhamento de gênero puramente binário. Por exemplo, a falta de espaços para pessoas que não são mulheres ou homens ou alinhadas com esses gêneros não é uma questão que só é relevante para quem não tem alinhamento, quando pessoas estelarianas, xênicas ou eclipsianas (que são lunarianas e solarianas) também enfrentam problemas com essas divisões.

Quando alguns termos e espaços surgiram para pessoas sem alinhamento de gênero, algumas pessoas tiveram que perguntar se a ideia era para pessoas sem alinhamento ou sem alinhamento binário, especialmente quando eram coisas acompanhadas por alternativas que eram apenas para pessoas com alinhamentos binários.

Mas e então, o que fazer?


Eu sinceramente não sei se há como "consertar" todas as impressões erradas sobre os sistemas de alinhamento de gênero. Ao menos não tão cedo e se cada pessoa continuar usando esses termos de forma diferente.

Não acho que é um problema que alinhamentos de gênero ainda existam. Mas pessoas precisam certamente parar de fazer presunções baseadas em conhecimentos limitados (como gêneros relacionados com mulher = gêneros femininos = "gêneros lunarianos" ou pessoas que não são alinhadas com homem ou com mulher = pessoas sem alinhamento), se querem parar de machucar ou afastar pessoas de termos que acham úteis.

Acho que estelariane e xênique me contemplam bastante, mas não são termos que faço questão de usar.

O sistema alibinário foi feito para poder ter termos que falam de questões diferentes sem elas serem divididas por que tipo de identidade de gênero a pessoa tem, mas ele não fala sobre questões de gênero enfrentadas especificamente por homens e pessoas solarianas ou por mulheres e pessoas lunarianas, ou qualquer equivalente disso.

A ideia de elementos de gênero foi cunhada para que pessoas possam expressar alguma relação com tais elementos independentemente de gênero, mas eles não possuem nenhum propósito político (de falar de questões específicas enfrentadas por certos grupos).

Também existem os termos proxmenina e proxmenino (e, sim, como qualquer outra identidade com esse tipo de nome, dá pra usar proxmulher, proxguri e afins). Eles podem servir como alinhamento, mas eu não sei o quanto os termos seriam confundidos com identidades de gênero, e/ou o quanto teriam o problema 1 descrito lá em cima.

Eu não sei se chamaria esses conceitos de alternativas, porque eles podem existir independentes de alinhamento de gênero. Mas se alguém quer apenas complementar sua identidade com outras coisas que a descrevem, esses sistemas podem ser usados. De qualquer forma, eu não acho que pessoas que usem o conceito de alinhamento de gênero precisem parar.

Também acho que a concepção do conceito foi importante para que pessoas pudessem se dar conta de como não é só porque uma pessoa é não-binária, ou mesmo porque tem um gênero completamente alheio a homem/mulher, que uma pessoa não pode "se alinhar" por ver que tem experiências em comum com pessoas binárias. E a cunhagem de alinhamentos parciais, mistos ou com identidades não-binárias também indica que pessoas podem sentir esse tipo de conexão com identidades fora do binário também.

O que mais quero que aconteça é que pessoas confiem mais nas experiências alheias sem precisar de rótulos. Alguém que é não-binárie e que quer usar um rótulo como aquileane deveria poder fazer isso sem ter que explicitar que é homem não-binárie, solariane, proxmenino, transmasculine ou qualquer outra coisa assim. Também seria legal confiar que, por exemplo, alguém bigênero homem/mulher não está invadindo ou traindo qualquer comunidade caso queira participar tanto de espaços de mulheres quanto de espaços de homens. Deixem que cada pessoa se descubra ou se identifique com o que achar melhor, ainda que "não faça sentido" para pessoas binárias.


Ikey Doherty vs Omarchy: Why He’s Building Barney Instead of Another Distro


Ikey Doherty, the creator of Solus and AerynOS, is back with Barney, a Rust tool that builds Linux distros from source. So that you can easily create your own Omarchy.

In a video posted on YouTube, the creator of Solus and AerynOS called the money behind DHH's distro absurd and promised to do it better with nothing. His answer is Barney, a Rust-based tool for building Linux distros from source.

Forgejo Scraping Protection: Nginx and Anubis


This is a little bit of a wall of text but I hope it will be a nice sample for such a setup.
This entry was edited (today, 11:33 AM)

The option to Block Large Media Elements in uBlock Origin(in Firefox) is nice. Saves net and speeds up loading


Remembered about this a Lemmy convo.

It is good. Animations or pictures beyond the selected size are replaced by a red border. Clicking it will load that image. Or you can temporarily turn it off for the website and reload the tab.

There is an option to exclude Websites from from it too. e.g. You can exclude Lemmy instances where you want to see images by default.

github.com/gorhill/uBlock/wiki…

Sharing it here since I had heard that uBo with full capabilities is now only available in Firefox

This entry was edited (today, 10:58 AM)

Replaced the window regulators in my car.


Replaced the window regulators in my car.

I got super lucky at a U-pull-it and found a 100% complete exact match for my car, it was at the lot cause it got front-end totaled. But everything I needed was interior and convertible related. (unfortunately it wasn't leather so the seats were worthless to me) My current regulators were super busted and I had 2 windows held up by zip-ties

Borrowed a friend and ripped the thing apart, and when it got cooler last night I swapped all the new regulators in. This car is special and a new regulator is like $350, so getting all 4 w/ a new cloth top for only $200 was a steal, it just needs some repairs but the cloth is in WAY better shape than the one that's on there atm.

The hardest part was getting the windows lined up correctly, first issue was fitting the glass to the sleds, I kept my original glass cause the tinting is different, they have to be installed out of the car, but need to be aligned while installed. After doing that there's a whole process with setting 3 different standoffs in a Stewart platform like arrangement. until it puts slight pressure on the seals both in front of and behind the glass.

And then there was the front left window, which didn't need the whole regulator, but the track it mounts too... at least I thought.

After installing the new track I noticed the entire mechanism flexes about 1/4" side-to-side when moving. And upon closer inspection, the nylon bushings that ride on the tracks are completely wore out on the new-to-me and old ones. At least the window works now though.

But it paid off and now I don't look stupid driving down the road with 2 rear windows jutting out when converted.

Next is replacing the hydraulic lifts with linear actuators and a brain. Those cursed Chrysler cylinders fail so often it was a miracle this one worked for the 2 months before a seal exploded and filled the back seats with stinky goo

1948 – Remember, Remember not (Van Leer Panel protest)


Peertube LiveChat Plugin

This entry was edited (today, 7:46 AM)

DRM from Korean eBook service Kyobo


So I caved and bought some books from Kyobo that were definitely not on thé usual channels and they have them in such a way that you can only read them from the app. So I downloaded them to my phone using the mobile app (the app doesn't support Linux and is basically a Rootkit anyway) and copied the files from Android/data. They're OEBPS by structure but come in regular folders, is it feasible to just zip them and import to Calibre?

Edit: I found a Calibre plugin for the DRM itself, so it's more "How to make this folder a file"

Edit: so you can just zip them up and import as epub BUT the DRM plugin only goes as far as the metadata, the content itself shows up garbled. Don't know how to get around that one...

This entry was edited (today, 7:51 AM)

#CrossBorderRail live stream - 9/7/2026, 7:55:07 PM


Morning previews of the day ahead, and evening summaries of what I learned during the day. During Jon Worth's #CrossBorderRail Spring Tour 2026.
This entry was edited (today, 6:01 AM)

#CrossBorderRail live stream - 9/8/2026, 6:21:33 AM


Morning previews of the day ahead, and evening summaries of what I learned during the day. During Jon Worth's #CrossBorderRail Spring Tour 2026.
This entry was edited (today, 6:01 AM)

#CrossBorderRail live stream - 9/8/2026, 7:51:13 PM


Morning previews of the day ahead, and evening summaries of what I learned during the day. During Jon Worth's #CrossBorderRail Spring Tour 2026.
This entry was edited (today, 6:01 AM)

#CrossBorderRail live stream - 9/9/2026, 5:13:40 AM


Morning previews of the day ahead, and evening summaries of what I learned during the day. During Jon Worth's #CrossBorderRail Spring Tour 2026.
This entry was edited (today, 6:01 AM)

How Urban Building Projects Influence Concrete Equipment Investment in Ethiopia


Urban building projects can significantly influence how contractors invest in concrete production equipment. As cities expand, construction activity often includes residential buildings, commercial properties, public facilities, mixed-use developments, and supporting infrastructure. These projects create different patterns of concrete demand. Some require continuous production for structural work, while others involve smaller and intermittent batches for foundations, columns, slabs, and auxiliary structures. As a result, equipment investment is increasingly shaped by the practical requirements of individual projects rather than by machine size alone.

For contractors evaluating a concrete mixer in Ethiopia, urban construction conditions can affect decisions about capacity, mobility, automation, and long-term operating costs. Limited site space, changing work schedules, labor availability, material supply, and transportation conditions all influence which equipment configuration is appropriate. The investment decision therefore extends beyond the initial purchase. Contractors must consider how efficiently the equipment can support concrete production throughout different stages of an urban building project.

Urban Building Growth Changes Concrete Production Requirements

Different Building Types Create Different Demand Patterns


Urban construction does not create a uniform demand for concrete. A multi-story residential building may require substantial volumes during foundation and structural stages, followed by lower concrete consumption as finishing work progresses. Commercial buildings can have different schedules, while smaller developments may need concrete only at specific intervals.

This variation affects equipment investment. Contractors working on repeated medium-scale projects may prefer equipment that can provide consistent production without the infrastructure requirements of a large batching facility. Larger contractors managing several simultaneous projects may require more substantial production capacity.

Foundation Work Often Creates an Early Production Peak


Excavation and foundation construction can generate intensive concrete demand during the early phase of a building project. Footings, foundation beams, retaining structures, columns, and base slabs may require significant quantities within a relatively short period.

Equipment must be capable of responding to this concentrated demand. However, purchasing a large production system solely for the foundation stage may not always be economical if concrete consumption decreases significantly later in the project.

Restricted Urban Sites Influence Equipment Size


Construction sites in growing urban areas are often surrounded by existing buildings, roads, commercial activity, and residential developments. Available working space may be limited.

A large concrete production installation can compete with aggregate storage, reinforcement preparation, formwork, cranes, material deliveries, and worker access. Consequently, contractors may place greater value on compact equipment that can fit into a restricted site layout.

Steep Slopes using self loader mixer

The physical footprint of a concrete mixer can therefore become an important investment factor. A machine does not operate in isolation. It must coexist with the entire construction ecosystem around it.

How Project Conditions Influence Concrete Mixer Investment

Production Capacity Must Match Actual Project Demand


One of the most important investment decisions involves selecting the appropriate production capacity. Higher output may appear advantageous, but unused capacity can increase equipment costs without producing a corresponding benefit.

Contractors need to examine average daily concrete demand, peak pouring periods, working hours, and the expected duration of each construction phase. A properly matched self loading mixer concrete can provide sufficient output while avoiding excessive investment in oversized equipment.

Capacity should therefore be viewed as a functional requirement rather than a simple indicator of machine quality.

Mobility Can Improve Equipment Utilization


Urban contractors may complete projects at different locations over relatively short periods. Once concrete work is finished at one site, the equipment may be required elsewhere.

Mobile or easily transportable equipment can improve asset utilization by allowing contractors to move the production system between projects. This reduces the risk of purchasing equipment that remains inactive after a single construction phase is completed.

Relocation Costs Should Be Considered


Mobility is not simply a technical feature. It has economic consequences. Equipment that requires extensive dismantling, transportation, and reinstallation can generate additional labor and time costs whenever a project changes.

For contractors managing multiple urban developments, easier relocation can become a meaningful advantage over the equipment's operating life.

Labor Availability Also Affects Equipment Selection


Concrete production traditionally depends on several repetitive activities, including loading aggregates, adding cement, measuring water, mixing, and transporting fresh concrete.

Equipment that integrates or simplifies some of these functions can reduce the number of manual operations required. This does not eliminate the need for skilled operators and quality control, but it can make the production process more organized and less dependent on fragmented manual work.

As construction schedules become tighter, predictable production processes may become increasingly valuable.

Why Concrete Mixer Price and Operating Costs Shape Investment Decisions

The Initial Purchase Price Is Only One Part of the Investment


When contractors compare concrete mixer price in Ethiopia, the machine's purchase price is naturally an important consideration. However, the lowest quotation does not necessarily represent the lowest long-term cost.

2 units of AIMIX self loading mixers operation

Fuel or electricity consumption, maintenance requirements, spare parts, transportation, labor, and equipment utilization can all influence the actual economic value of the investment. A cheaper machine that requires frequent repairs or consumes excessive fuel may become more expensive during its operating life.

For this reason, contractors should compare total ownership costs rather than focusing exclusively on the initial equipment price.

Material Handling Can Affect Overall Productivity


Concrete production depends on a continuous flow of aggregates, cement, water, and other materials. If material handling is inefficient, the mixer may spend significant periods waiting rather than producing concrete.

Urban building projects can make this issue more pronounced because delivery schedules and storage areas may be restricted. Equipment investment should therefore consider how easily materials can be supplied to the mixer within the available site layout.

A Balanced System Reduces Operational Bottlenecks


The mixer is only one part of the production process. Aggregate supply, cement storage, loading equipment, water availability, and concrete transportation must operate at compatible rates.

A highly productive mixer cannot compensate for an inefficient material supply system. Similarly, additional supporting equipment may provide little value if the project's concrete demand remains modest. Investment decisions should consider the complete production sequence.

Future Project Use Influences the Value of the Equipment


A contractor purchasing a large concrete mixer should also consider future applications. Equipment selected for one urban building project may later be used for housing developments, commercial structures, infrastructure works, or other concrete-intensive activities.

Versatility can improve long-term utilization. A machine that can adapt to different project sizes and operating conditions may provide greater value than equipment designed around a single narrowly defined application.

Urban Construction Encourages More Strategic Equipment Investment


Urban building development in Ethiopia influences concrete equipment investment by creating a combination of practical demands. Contractors need adequate production capacity, but they may also face limited site space. They require reliable concrete supply, yet demand can fluctuate between construction stages. Equipment may need to remain at one site for months or move between multiple projects.

These variables encourage a more selective approach to machinery investment. The appropriate concrete mixer in Ethiopia depends on the contractor's typical project profile, expected concrete volume, available labor, site conditions, and future equipment utilization.

Price remains important, but it should be evaluated alongside productivity and operating requirements. When comparing concrete mixer price in Ethiopia, contractors can achieve a clearer investment decision by examining capacity, fuel consumption, maintenance, mobility, material handling, and after-sales support together.

Ultimately, urban construction does not necessarily require the largest concrete production equipment. It requires equipment that fits the construction environment. A properly matched mixer can support foundation work, structural concrete production, and multiple future projects without creating unnecessary operational complexity. As urban building activity continues to diversify, the most valuable equipment investment is likely to be the one that balances production capability with the realities of the jobsite.

```

Festplatten und SSDs unter Linux mit Smartmontools prüfen – SMART und Selbsttests


Smartmontools 7.5 unter Debian/Ubuntu: HDDs, SATA-SSDs und NVMe-Laufwerke prüfen, SMART-Werte lesen, Kurz- und Langtests starten und Warnzeichen erkennen.

Überarbeitet am 9. September 2026.

Bei einem Server gehören Festplatten und SSDs für mich zu den Dingen, die ich lieber kontrolliere, bevor sie sich mit einem Totalausfall melden. Dafür sind die Smartmontools unter Linux weiterhin eines der wichtigsten Werkzeuge.

Das Paket enthält vor allem smartctl für manuelle Prüfungen und smartd für die laufende Überwachung im Hintergrund. Aktuell ist Smartmontools 7.5.

Table of Contents
Toggle

Installation unter Debian und Ubuntu

sudo apt update
sudo apt install smartmontools

Version prüfen:
smartctl --version

Unter Debian Trixie ist Smartmontools 7.5 beispielsweise auch über die Backports verfügbar.

Welche Laufwerke sind vorhanden?


Für einen schnellen Überblick:

lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Typische Gerätenamen sind:
  • /dev/sda für SATA/SAS-Laufwerke,
  • /dev/nvme0 beziehungsweise /dev/nvme0n1 für NVMe.

Smartmontools kann unterstützte Geräte auch selbst suchen:

sudo smartctl --scan

Kompletten SMART-Bericht anzeigen


Bei einer SATA-Festplatte oder SSD:

sudo smartctl -a /dev/sda

Für ausführlichere Informationen:
sudo smartctl -x /dev/sda

Bei NVMe funktioniert entsprechend:
sudo smartctl -a /dev/nvme0

Smartmontools 7.5 unterstützt auch aktuelle NVMe-SMART-/Health-Informationen und Selbsttests.

Nicht nur auf „PASSED“ schauen


Ein globales SMART-Ergebnis wie PASSED ist hilfreich, aber kein Freifahrtschein. Ein Laufwerk kann bereits auffällige Werte zeigen, bevor der Gesamtstatus endgültig auf Fehler springt.

Bei klassischen HDDs achte ich besonders auf:

  • Reallocated Sector Count – bereits ersetzte problematische Sektoren,
  • Current Pending Sector – aktuell verdächtige, noch nicht stabil lesbare Sektoren,
  • Offline Uncorrectable – nicht korrigierbare Sektoren,
  • Fehler- und Selbsttestprotokolle.

Ein einzelner herstellerspezifischer Rohwert sollte allerdings nicht ohne Kontext interpretiert werden. SMART-Attribute unterscheiden sich zwischen Herstellern und Laufwerkstypen.

Bei SSD und NVMe zählen andere Werte


Bei SSDs interessieren zusätzlich Verschleiß und verfügbare Reserve. Smartmontools 7.5 kann in der JSON-Ausgabe unter anderem Werte wie endurance_used und spare_available für unterstützte Geräte liefern.

Für Automatisierung ist JSON praktisch:

sudo smartctl -j -a /dev/nvme0

Damit können Monitoring-Skripte Werte verarbeiten, ohne die normale Textausgabe zerlegen zu müssen.

Kurzen Selbsttest starten

sudo smartctl -t short /dev/sda

Smartctl nennt anschließend normalerweise, wie lange der Test ungefähr dauert. Danach Ergebnis anzeigen:
sudo smartctl -l selftest /dev/sda

Langen Selbsttest durchführen

sudo smartctl -t long /dev/sda

Auch hier danach:
sudo smartctl -l selftest /dev/sda

Der lange Test kann je nach Größe des Laufwerks deutlich länger dauern. Er läuft normalerweise intern im Laufwerk; trotzdem starte ich so etwas auf einem Produktivserver lieber bewusst und nicht zufällig während einer ohnehin hohen Lastphase.

NVMe-Selbsttests


Aktuelle Smartmontools-Versionen unterstützen Selbsttests auch bei passenden NVMe-Geräten:

sudo smartctl -t short /dev/nvme0
sudo smartctl -l selftest /dev/nvme0

Nicht jedes Laufwerk unterstützt jede Funktion. Wenn Smartctl einen Test ablehnt, sollte man nicht mit irgendwelchen erzwungenen Optionen herumprobieren, sondern zuerst die Fähigkeiten des Geräts prüfen.

smartd für laufende Überwachung


Statt nur gelegentlich manuell hineinzusehen, kann smartd Laufwerke regelmäßig überwachen.

Status prüfen:

systemctl status smartmontools

Je nach Distribution heißt die Unit auch smartd. Die zentrale Konfiguration liegt normalerweise unter:
/etc/smartd.conf

Bevor ich Benachrichtigungen aktiviere, kontrolliere ich dort genau, welche Geräte automatisch erkannt werden und wohin Warnungen gehen.

SMART ersetzt kein Backup


Das ist mir wichtig: SMART ist Frühwarnung, keine Versicherung. Ein Laufwerk kann auch ohne lange Vorwarnung sterben.

Deshalb kombiniere ich Laufwerksüberwachung mit echten Backups. Dazu passen meine Artikel BorgBackup unter Debian/Ubuntu und Backup richtig planen.

Bei RAID jedes physische Laufwerk prüfen


Ein Software-RAID schützt vor dem Ausfall eines einzelnen Datenträgers, macht SMART aber nicht überflüssig. Im Gegenteil: Bei einem RAID möchte ich wissen, ob ein Mitglied bereits Fehler entwickelt, bevor noch ein zweites Laufwerk Probleme bekommt.

Darum prüfe ich RAID-Status und SMART-Werte getrennt.

Fazit


Smartmontools gehört für mich auf jeden Linux-Server mit lokalen Laufwerken. Ein gelegentliches smartctl -a, regelmäßige Selbsttests und eine funktionierende Backup-Strategie geben wesentlich mehr Sicherheit als erst dann auf die Platte zu schauen, wenn das System bereits I/O-Fehler meldet.

Quellen: Debian Manpages: smartctl 7.5 und Smartmontools 7.5 Release.

This entry was edited (yesterday, 10:44 PM)

Webserver mit Security-Headern absichern – sinnvoll statt blind kopieren


Security-Header für Nginx und Apache 2026: HSTS, nosniff, Referrer-Policy und CSP sinnvoll einsetzen – ohne Cookies, CORS oder Subdomains kaputtzukonfigurieren.

Überarbeitet am 8. September 2026.

Security-Header sind eine schöne zusätzliche Schutzschicht für Webseiten. Mein alter Artikel hatte allerdings genau das Problem, vor dem ich heute warnen würde: Ich hatte mehrere Header global auf sämtliche Websites gesetzt, ohne die Folgen für jede Anwendung einzeln zu prüfen.

Das ging sogar einmal schief. Eine globale Regel, die jedes Set-Cookie nachträglich mit HttpOnly; Secure versehen sollte, sorgte bei mir dafür, dass ein Cookie-Banner nicht mehr richtig funktionierte. Seitdem gilt für mich: Security-Header nicht nach Punkteliste einschalten, sondern verstehen, testen und passend zur Anwendung setzen.

Table of Contents
Toggle

1. X-Content-Type-Options: nosniff


Dieser Header ist ein guter und meist unkomplizierter Anfang:

X-Content-Type-Options: nosniff

Er weist den Browser an, die vom Server angegebenen MIME-Typen zu respektieren, statt den Inhalt selbst anders zu interpretieren.

Nginx:

add_header X-Content-Type-Options "nosniff" always;

Apache:
Header always set X-Content-Type-Options "nosniff"

2. Referrer-Policy


Mit der Referrer-Policy lässt sich begrenzen, welche Informationen eine aufgerufene Fremdseite über die Herkunft eines Besuchers erhält.

Ein vernünftiger allgemeiner Wert ist:

Referrer-Policy: strict-origin-when-cross-origin

Das ist inzwischen auch der Browser-Standard. Wer noch weniger Informationen nach außen geben möchte, kann beispielsweise strict-origin, same-origin oder no-referrer prüfen. Die strengste Einstellung ist aber nicht automatisch die beste, wenn Anwendungen Referrer-Informationen benötigen.

3. HSTS – sehr sinnvoll, aber nicht leichtfertig mit preload


HTTP Strict Transport Security teilt dem Browser mit, dass eine Domain künftig nur über HTTPS angesprochen werden soll:

Strict-Transport-Security: max-age=31536000

Nginx:
add_header Strict-Transport-Security "max-age=31536000" always;

Apache:
Header always set Strict-Transport-Security "max-age=31536000"

Wichtig: Den Header nur über HTTPS ausliefern. Browser ignorieren HSTS über eine unverschlüsselte HTTP-Verbindung ohnehin.

Mit includeSubDomains gilt die Regel zusätzlich für sämtliche Subdomains. Das sollte man erst aktivieren, wenn wirklich jede aktuelle und zukünftige Subdomain per HTTPS funktioniert.

Und preload würde ich nicht mehr wie früher einfach in eine Beispielkonfiguration schreiben. Wer seine Domain in eine Browser-Preload-Liste eintragen lässt, bindet sich sehr stark an HTTPS. Vorher unbedingt alle Subdomains prüfen und die Folgen verstehen.

4. Schutz vor Einbettung: CSP frame-ancestors


Früher wurde dafür häufig nur X-Frame-Options gesetzt. Dieser Header funktioniert weiterhin, moderner und flexibler ist aber die CSP-Direktive frame-ancestors.

Wenn eine Seite überhaupt nicht in Frames eingebettet werden soll:

Content-Security-Policy: frame-ancestors 'none';

Wenn Einbettung aus derselben Origin erlaubt sein soll:
Content-Security-Policy: frame-ancestors 'self';

Bei Nextcloud, Office-Anwendungen, Payment-Diensten oder eingebetteten Inhalten sollte man so eine Regel aber nicht blind setzen. Genau dort können Frames legitim benötigt werden.

5. Content-Security-Policy: mächtig, aber individuell


CSP kann unter anderem verhindern, dass unerwartete Skripte, Styles oder andere Ressourcen geladen werden. Sie gehört aber nicht in eine universelle Copy-and-Paste-Zeile für WordPress, Nextcloud und jede andere Anwendung.

Mein alter Artikel hatte beispielsweise eine lange CSP mit 'unsafe-inline' und 'unsafe-eval' sowie fest verdrahteten Fremddomains. So etwas altert schnell und kann entweder Funktionen blockieren oder ein falsches Gefühl von Sicherheit erzeugen.

Mein heutiger Weg wäre:

  1. prüfen, welche Ressourcen die Anwendung tatsächlich benötigt,
  2. eine CSP zunächst mit Content-Security-Policy-Report-Only testen,
  3. Verstöße auswerten,
  4. danach schrittweise eine wirksame CSP aktivieren.

Bei fertigen Anwendungen wie Nextcloud würde ich außerdem zuerst deren offizielle Dokumentation beziehungsweise bereits gesetzte Header prüfen, statt darüber global eine eigene Richtlinie zu legen.

6. X-XSS-Protection nicht mehr als modernen Schutz empfehlen


In meinem alten Beispiel stand:

X-XSS-Protection: 1; mode=block

Diesen Header würde ich heute nicht mehr als moderne Sicherheitsmaßnahme aufnehmen. Die entsprechenden alten Browser-XSS-Filter sind veraltet. Moderne Anwendungen sollten XSS vor allem durch korrektes Escaping, sichere Frameworks und eine sinnvoll gestaltete Content Security Policy verhindern.

7. CORS nicht global mit * freigeben


Ebenfalls problematisch war mein altes Beispiel:

Access-Control-Allow-Origin: *

CORS ist keine allgemeine „Webseite sicherer machen“-Option. Damit wird festgelegt, welche fremden Origins Browser auf bestimmte Ressourcen zugreifen lassen. Ein Wildcard-Wert kann für öffentliche APIs oder statische öffentliche Ressourcen sinnvoll sein, gehört aber nicht pauschal auf jede Website.

Wenn eine Anwendung CORS benötigt, sollte die erlaubte Origin gezielt passend zu genau diesem Anwendungsfall gesetzt werden.

8. Cookies nicht global im Webserver umschreiben


Genau damit hatte ich mir damals selbst Probleme gebaut:

Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Die Absicht war gut: Cookies sollten nur über HTTPS übertragen und vor JavaScript geschützt werden. Aber nicht jedes Cookie darf HttpOnly sein. Ein Cookie, das clientseitiges JavaScript bewusst lesen muss, funktioniert danach möglicherweise nicht mehr.

Cookie-Eigenschaften wie Secure, HttpOnly und SameSite sollten deshalb vorzugsweise von der Anwendung beziehungsweise dem Framework passend zum jeweiligen Cookie gesetzt werden – nicht per globalem Such-und-Ersetzen im Webserver.

9. Permissions-Policy nur gezielt verwenden


Mit Permissions-Policy können Browserfunktionen wie Kamera, Mikrofon oder Geolocation eingeschränkt werden. Die Browserunterstützung ist allerdings je nach Direktive unterschiedlich. Auch hier gilt: Nicht wahllos alles abschalten, wenn eine Anwendung beispielsweise Videotelefonie oder Standortzugriff benötigt.

Für eine einfache Webseite ohne solche Funktionen könnte man einzelne Features bewusst sperren, beispielsweise:

Permissions-Policy: geolocation=(), camera=(), microphone=()

Vor dem Produktiveinsatz immer die tatsächlich benötigten Funktionen und Browserkompatibilität prüfen.

Meine kleine Basis für normale Webseiten


Für eine klassische HTTPS-Webseite ohne besondere Anforderungen könnte eine vorsichtige Nginx-Basis beispielsweise so beginnen:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000" always;

Bei Apache entsprechend:
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000"

CSP, frame-ancestors, CORS und Permissions Policy würde ich anschließend pro Anwendung ergänzen und testen.

Header überprüfen


Nach Änderungen zunächst Webserver-Konfiguration testen:

sudo nginx -t

beziehungsweise:
sudo apachectl configtest

Die tatsächlichen Response-Header lassen sich beispielsweise mit curl ansehen:
curl -I https://example.de

Zusätzlich sind Browser-Entwicklertools und der Mozilla Observatory hilfreich.

Fazit


Security-Header sind sinnvoll – aber mehr Header bedeutet nicht automatisch mehr Sicherheit. Mein größter Lernpunkt aus der alten Konfiguration ist, globale Regeln nur dann zu setzen, wenn ich sicher bin, dass sie zu allen darunter laufenden Anwendungen passen.

Für Nextcloud habe ich die wichtigsten Servermaßnahmen separat beschrieben: Nextcloud richtig absichern. Und falls Nginx selbst einmal nicht startet: Nginx „Unit is masked“ beheben.

Quellen: MDN: HSTS, MDN: X-Content-Type-Options, MDN: Referrer-Policy und MDN: CSP frame-ancestors.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 9:54 PM)

Android-Smartphone mit scrcpy am PC spiegeln und steuern


Android per USB am Linux-, Windows- oder macOS-PC spiegeln und steuern: scrcpy 4.x, Installation, USB-Debugging und praktische Befehle.

Überarbeitet am 8. September 2026.

scrcpy gehört für mich zu diesen kleinen Open-Source-Werkzeugen, die unglaublich praktisch sein können. Damit lässt sich der Bildschirm eines Android-Smartphones auf Linux, Windows oder macOS spiegeln und das Gerät mit Maus und Tastatur bedienen.

Das kann beispielsweise helfen, wenn der Touchscreen Probleme macht oder man das Smartphone bequem vom Rechner aus bedienen möchte.

Table of Contents
Toggle

Was scrcpy 2026 kann


Die aktuelle scrcpy-Reihe kann deutlich mehr als die Version aus meinem ursprünglichen Artikel:

  • Bildschirm über USB oder TCP/IP spiegeln,
  • Steuerung mit Tastatur und Maus,
  • bis zu 120 fps je nach Gerät,
  • Audio-Weiterleitung ab Android 11,
  • Bildschirmaufnahme,
  • Zwischenablage zwischen PC und Smartphone,
  • virtuelle Displays,
  • HID-Tastatur/-Maus und Gamepads,
  • kein Root und kein dauerhaft installiertes Android-Programm nötig.

Unterstützt wird Android ab Version 5.0. Für die normale Spiegelung und Steuerung muss USB-Debugging auf dem Gerät aktiviert sein.

Eine wichtige Grenze


Wenn USB-Debugging auf dem Smartphone nicht aktiviert beziehungsweise die Verbindung zum Computer nicht bestätigt wurde, kann die normale scrcpy-Verbindung nicht genutzt werden. Wer scrcpy als Notfallwerkzeug im Hinterkopf hat, sollte es deshalb einmal einrichten und testen, solange das Smartphone normal bedienbar ist.

Unter Linux installieren


Auf vielen Linux-Distributionen ist scrcpy direkt paketiert. Unter Debian/Ubuntu beispielsweise:

sudo apt update
sudo apt install adb scrcpy

Die Distributionspakete können hinter der aktuellen Projektversion zurückliegen. Das scrcpy-Projekt weist ausdrücklich darauf hin, dass Genymobile/scrcpy die einzige offizielle Projektquelle ist. Für die neueste Version sollte man deshalb die dort dokumentierten Installationswege nutzen.

Verbindung testen und starten


Smartphone per USB verbinden. Anschließend:

scrcpy

Wenn alles eingerichtet ist, öffnet sich ein Fenster mit dem Smartphone-Bild. Das Gerät lässt sich direkt mit Maus und Tastatur bedienen.

Praktische Befehle


Auflösung reduzieren:

scrcpy --max-size=1280

Audio deaktivieren:
scrcpy --no-audio

Smartphone-Bildschirm während der PC-Steuerung ausschalten:
scrcpy --turn-screen-off

Sitzung aufnehmen:
scrcpy --record=aufnahme.mp4

Drahtlose Verbindung


scrcpy kann auch über TCP/IP arbeiten. Für den normalen Einstieg würde ich trotzdem zuerst USB nutzen, weil dabei weniger zusätzliche Fehlerquellen entstehen.

OTG-Modus


scrcpy unterstützt auch einen OTG-Modus, bei dem Eingabegeräte per USB-HID simuliert werden können. Dieser Modus benötigt kein USB-Debugging, ist aber nicht dasselbe wie die normale Bildschirmspiegelung.

Fazit


scrcpy ist 2026 noch deutlich vielseitiger als bei meinem ersten Artikel. Es ist schnell, quelloffen, werbefrei und benötigt weder Cloudkonto noch Root-Zugriff. Für Android-Nutzer ist es ein richtig schönes Werkzeug für die tägliche Bedienung und Fehlersuche.

Quelle: Offizielles scrcpy-Projekt von Genymobile.

This entry was edited (yesterday, 9:52 PM)

Nextcloud mit Plesk und Nginx betreiben – PHP-FPM, Proxy-Modus und wichtige Einstellungen


Nextcloud unter Plesk Obsidian mit Nginx und PHP-FPM betreiben: Proxy-Modus, PHP-Handler, .well-known-Weiterleitungen und typische Reverse-Proxy-Fallen 2026.

Überarbeitet am 8. September 2026.

Dieser Artikel war ursprünglich eine Mischung aus Plesk-, Nextcloud- und Collabora-Konfigurationen. Das war irgendwann kaum noch wartbar: Nextcloud hat seine Nginx-Regeln mehrfach angepasst und Collabora verwendet heute andere Pfade als früher. Deshalb trenne ich die Themen inzwischen sauber.

Hier geht es nur noch darum, Nextcloud unter Plesk Obsidian mit Nginx und PHP-FPM sinnvoll zu betreiben. Für Office gibt es eine eigene aktuelle Anleitung: Nextcloud Office mit Collabora einrichten.

Table of Contents
Toggle

1. Nginx in Plesk aktivieren


Bei einer aktuellen Plesk-Installation ist Nginx normalerweise bereits vorhanden. Prüfen kannst du das unter Tools & Einstellungen → Service-Verwaltung. Dort sollte der Reverse-Proxy-Service Nginx laufen.

Falls Nginx als PHP-Handler nicht angeboten wird, prüfe außerdem unter Tools & Einstellungen → Updates → Komponenten hinzufügen/entfernen → Webhosting, ob der Nginx-Webserver installiert ist.

2. Apache für diese Domain wirklich umgehen?


Plesk arbeitet standardmäßig mit Nginx vor Apache. Eine einzelne Domain kann aber auch nur über Nginx ausgeliefert werden.

Dazu gehst du bei der Nextcloud-Domain auf:

Websites & Domains → Einstellungen für Apache & Nginx

und deaktivierst im Nginx-Bereich den Proxymodus.

Wichtig: Bei nginx-only steht für PHP nur ein von Nginx bedienter PHP-FPM-Handler zur Verfügung. In den PHP-Einstellungen der Domain muss deshalb ein passender FPM-Handler, bedient von Nginx, ausgewählt sein.

3. Nicht meine alte Nginx-Konfiguration kopieren


Im alten Artikel stand eine komplette Nextcloud-Konfiguration aus einer längst vergangenen Version. Darin waren Pfade und Regeln enthalten, die heute nicht mehr dem offiziellen Beispiel entsprechen.

Nextcloud veröffentlicht eine gepflegte Referenzkonfiguration für Nginx. Diese sollte immer Ausgangspunkt sein:

Nextcloud Administration Manual: NGINX configuration

Plesk generiert allerdings selbst den Server-Block der Domain. Deshalb würde ich nicht einfach den kompletten offiziellen server { ... }-Block in „Zusätzliche Nginx-Anweisungen“ kopieren. Stattdessen müssen die für die eigene Installation nötigen Direktiven in die von Plesk erzeugte Struktur integriert werden.

4. .well-known für CalDAV und CardDAV


Ein Klassiker in der Nextcloud-Adminübersicht sind Warnungen zu CalDAV/CardDAV. Bei einer Installation direkt unter der Domain verweist die aktuelle Nextcloud-Dokumentation unter anderem auf folgende Weiterleitungen am vorgeschalteten Nginx:

location = /.well-known/carddav {
    return 301 $scheme://$host/remote.php/dav;
}

location = /.well-known/caldav {
    return 301 $scheme://$host/remote.php/dav;
}

Weitere /.well-known-Pfade sollten nicht pauschal blockiert werden. Die aktuelle Nextcloud-Nginx-Doku enthält dafür die jeweils passende Regel.

5. Client-IP bei Reverse Proxies richtig behandeln


Falls vor Nextcloud noch ein weiterer Reverse Proxy, Load Balancer oder Container-Proxy sitzt, müssen trusted_proxies und gegebenenfalls forwarded_for_headers in der config.php korrekt gesetzt sein.

Das ist nicht nur Kosmetik: Erkennt Nextcloud alle Besucher als dieselbe Proxy-IP, kann die eingebaute Brute-Force-Erkennung plötzlich völlig normale Nutzer drosseln. Umgekehrt darf Nextcloud auch nicht beliebige vom Client gelieferte Forwarded-Header vertrauen, weil sich sonst IP-Adressen fälschen lassen.

Die aktuelle Dokumentation dazu: Nextcloud: Reverse proxy.

6. Nach Änderungen testen


Nach Anpassungen kontrolliere ich mindestens:

nginx -t

und anschließend die Nextcloud-Adminübersicht unter Verwaltung → Übersicht. Zusätzlich sollte man Anmeldung, Datei-Upload, WebDAV sowie Kalender- und Kontakte-Synchronisation testen.

Wenn Nginx selbst mit Unit nginx.service is masked nicht startet, habe ich dafür ebenfalls eine eigene aktuelle Anleitung: Nginx „Unit is masked“ beheben.

7. Nextcloud-Härtung nicht vergessen


Der Webserver ist nur ein Teil des Setups. HTTPS, Updates, 2FA, Brute-Force-Schutz, Backups und eine korrekte Proxy-Konfiguration gehören ebenfalls dazu. Mehr dazu in Nextcloud richtig absichern.

Fazit


Plesk und Nextcloud funktionieren auch 2026 gut zusammen, wenn man Plesk seine Webserver-Konfiguration verwalten lässt und die Nextcloud-spezifischen Regeln gezielt ergänzt. Was ich heute vermeiden würde: eine jahrealte komplette Nginx-Konfiguration aus einem Blogbeitrag blind in Plesk einzufügen.

Quellen: Plesk Obsidian: Apache- und Nginx-Einstellungen, Nextcloud: NGINX configuration und Nextcloud: Reverse proxy.


Nextcloud Office mit Collabora einrichten: Docker, Reverse Proxy und Tests


Überarbeitet am 8. September 2026.

Diese Anleitung ist einer der Artikel, bei denen das Alter besonders deutlich geworden ist. Meine ursprüngliche Version brauchte noch einen speziellen Ubuntu-16.04-Kernel und hantierte mit AUFS. Das ist heute Geschichte. Nextcloud Office basiert weiterhin auf Collabora Online beziehungsweise CODE, lässt sich aber inzwischen wesentlich entspannter einrichten.

Für kleine private Installationen gibt es sogar einen eingebauten CODE-Server. Wer etwas mehr Leistung möchte, betreibt Collabora separat – zum Beispiel als Docker-Container hinter einem Reverse Proxy. Genau diesen Weg zeige ich hier.

Falls Docker auf deinem Server noch fehlt, findest du hier meine aktualisierte Anleitung: Docker und Docker Compose unter Debian und Ubuntu installieren.

Table of Contents
Toggle

Was ist Nextcloud Office eigentlich?


Nextcloud Office ist die Office-Integration innerhalb von Nextcloud. Die eigentliche Bearbeitung übernimmt Collabora Online. Damit lassen sich unter anderem DOCX-, XLSX-, PPTX- und OpenDocument-Dateien direkt im Browser öffnen und gemeinsam bearbeiten.

Wenn du erstmal nur ausprobieren möchtest, ob dir das gefällt, reicht für eine kleine Installation oft der Built-in CODE Server. Er lässt sich als Nextcloud-App installieren und funktioniert in vielen Setups ohne zusätzlichen Container. Nextcloud weist allerdings selbst darauf hin, dass ein separater Collabora-Server für bessere Performance sinnvoller ist.

1. Eigene Subdomain für Collabora vorbereiten


Für einen separaten Collabora-Server würde ich eine eigene Subdomain verwenden, zum Beispiel:
office.example.deCode-Sprache: CSS (css)
Die Subdomain zeigt auf deinen Server und bekommt ein gültiges TLS-Zertifikat. Auch deine Nextcloud sollte natürlich über HTTPS erreichbar sein. Nextcloud und Collabora sollten dasselbe Protokoll verwenden – praktisch also beide HTTPS.

Mehr zu den grundlegenden Sicherheitsmaßnahmen findest du in Nextcloud richtig absichern.

2. Collabora CODE als Docker-Container starten


Das offizielle CODE-Image heißt weiterhin collabora/code. Zuerst laden wir es:
docker pull collabora/code
Danach starten wir Collabora nur auf localhost. So ist Port 9980 nicht direkt aus dem Internet erreichbar:
docker run -t -d \
-p 127.0.0.1:9980:9980 \
-e 'aliasgroup1=https://cloud.example.de:443' \
--restart always \
--cap-add MKNOD \
--name collabora \
collabora/codeCode-Sprache: JavaScript (javascript)
cloud.example.de ersetzt du durch die Domain deiner Nextcloud. Der Container lauscht anschließend nur auf 127.0.0.1:9980. Von außen kommt man später ausschließlich über den Reverse Proxy an Collabora heran.

3. Reverse Proxy vor Collabora setzen


Collabora benötigt einen Reverse Proxy, der die öffentliche Adresse https://office.example.de auf den lokalen Dienst an Port 9980 weiterleitet. Anders als in sehr alten Anleitungen heißen die wichtigen Pfade heute unter anderem:

  • /browser
  • /hosting/discovery
  • /hosting/capabilities
  • /cool
  • WebSocket-Verbindungen unter /cool/.../ws

Wer noch eine alte Konfiguration mit /lool und /loleaflet hat, sollte sie deshalb überprüfen. Die aktuellen Collabora-Komponenten verwenden coolwsd, /cool und /browser.

Da ich selbst Nginx nutze, würde ich dafür die aktuelle Reverse-Proxy-Vorlage von Collabora beziehungsweise Nextcloud als Ausgangspunkt nehmen. Besonders wichtig ist, dass die WebSocket-Verbindung mit durchgereicht wird. Eine reine normale HTTP-Weiterleitung reicht nicht.

4. Erst Collabora testen


Bevor ich Nextcloud konfiguriere, teste ich den Office-Server separat. Diese beiden Adressen sollten über den Browser erreichbar sein:
office.example.de/hosting/capa…
office.example.de/hosting/disc… JavaScript (javascript)
Auch direkt vom Nextcloud-Server aus kann man testen:
curl office.example.de/hosting/capa…
curl office.example.de/hosting/disc… JavaScript (javascript)
Wenn das schon nicht funktioniert, braucht man in Nextcloud noch gar nicht weiterzusuchen. Dann liegt das Problem eher bei DNS, Zertifikat, Firewall oder Reverse Proxy.

5. Nextcloud Office installieren und verbinden


In Nextcloud gehst du zu Apps → Office & Text und installierst beziehungsweise aktivierst Nextcloud Office.

Anschließend findest du unter Administrationseinstellungen → Office die Verbindung zum Collabora-Server. Dort trägst du ein:
office.example.deCode-Sprache: JavaScript (javascript)
Wenn alles stimmt, sollte Nextcloud die Verbindung erkennen. Danach kannst du direkt eine neue Textdatei oder Tabelle erstellen und testen.

6. WOPI-Zugriffe einschränken


Ein Punkt, den es in meiner alten Anleitung noch gar nicht gab: Nextcloud empfiehlt ausdrücklich, WOPI-Anfragen auf die erwarteten Collabora-Server zu begrenzen. Die entsprechende Allow-Liste findest du in den Office-Administrationseinstellungen.

Dort sollte möglichst nur die IP beziehungsweise das Netz eingetragen werden, aus dem dein Collabora-Server Nextcloud tatsächlich erreicht. Das verhindert, dass beliebige andere Systeme WOPI-Anfragen an deine Nextcloud stellen können.

7. Typische Fehler


Wenn Nextcloud Office nicht verbindet, prüfe ich in dieser Reihenfolge:

  • Kann der Browser Nextcloud und Collabora über HTTPS erreichen?
  • Kann Nextcloud office.example.de erreichen?
  • Kann Collabora wiederum die Nextcloud-Domain erreichen?
  • Ist das TLS-Zertifikat gültig?
  • Werden die /cool-WebSockets vom Reverse Proxy korrekt weitergeleitet?
  • Ist die WOPI-Allow-Liste korrekt?

Für den Container selbst helfen die Logs:
docker logs --tail 100 collabora
Die Nextcloud-Logs sollte man parallel ebenfalls ansehen. Sehr häufig ist es kein Office-Fehler, sondern schlicht eine nicht funktionierende Verbindung in eine der beiden Richtungen.

8. Collabora aktualisieren


Da CODE regelmäßig aktualisiert wird, sollte auch der Container nicht jahrelang unangetastet bleiben:
docker pull collabora/code
Anschließend wird der Container mit demselben Startbefehl neu erstellt. Wer stattdessen Docker Compose verwendet, kann das entsprechend mit docker compose pull und docker compose up -d erledigen.

Mein Fazit nach der Überarbeitung


Der Unterschied zu meiner ersten Collabora-Anleitung ist schon ziemlich absurd: Kein Xenial-Proposed, kein Kernel 4.4, kein AUFS-Gefrickel mehr. Für kleine Instanzen reicht heute sogar der eingebaute CODE-Server. Wer es etwas sauberer und performanter möchte, stellt einen separaten Collabora-Container hinter eine eigene HTTPS-Subdomain.

Wenn du noch am Anfang mit Nextcloud bist, findest du in Was bietet Nextcloud 2026? einen Überblick darüber, was die Cloud inzwischen alles kann.

Weiterführend: Nextcloud Office installieren, Collabora per Docker und Troubleshooting.


This entry was edited (yesterday, 9:45 PM)

aria2 mit Docker Compose sicher betreiben – RPC-Token und WebUI nur lokal


aria2 mit WebUI per Docker Compose betreiben: aktueller Container, RPC-Token, persistente Downloads und sichere localhost-Bindings statt offenem Port 6800.

Überarbeitet am 8. September 2026.

aria2 ist auch 2026 noch ein praktischer Download-Client für HTTP/HTTPS, FTP/SFTP, BitTorrent und Metalink. Meine alte Docker-Anleitung hatte allerdings einen ziemlich unschönen Haken: Die RPC-Schnittstelle und die WebUI wurden direkt auf öffentliche Serverports gelegt. Das würde ich heute nicht mehr so machen.

In dieser aktualisierten Variante laufen WebUI und RPC deshalb ausschließlich auf 127.0.0.1. Für die RPC-Schnittstelle wird zusätzlich ein Secret verwendet.

Table of Contents
Toggle

Voraussetzungen


Docker und Docker Compose sollten bereits installiert sein. Falls nicht: Docker und Docker Compose unter Debian/Ubuntu installieren.

Eine Erklärung zum Aufbau von Compose-Dateien findest du hier: Docker Compose erklärt.

Projektordner anlegen

sudo mkdir -p /opt/aria2/{downloads,config}
cd /opt/aria2

Für den RPC-Schlüssel verwenden wir eine .env-Datei:
nano .env
ARIA2_SECRET=hier-ein-langes-zufaelliges-secret-eintragen

Die Datei sollte nicht unnötig für andere Benutzer lesbar sein:
chmod 600 .env

compose.yaml erstellen

services:
  aria2:
    image: abcminiuser/docker-aria2-with-webui:latest-ng
    container_name: aria2
    restart: unless-stopped
    ports:
      - "127.0.0.1:6800:6800"
      - "127.0.0.1:6880:80"
    volumes:
      - ./downloads:/data
      - ./config:/conf
    environment:
      SECRET: ${ARIA2_SECRET}
      PUID: 1000
      PGID: 1000

PUID und PGID müssen zu dem Benutzer passen, der auf die Download-Verzeichnisse zugreifen soll. Die Werte kannst du beispielsweise mit id BENUTZERNAME prüfen.

Container starten

docker compose up -d
docker compose ps
docker compose logs --tail=100 aria2

Warum die Ports nur auf localhost liegen


Die aria2-RPC-Schnittstelle ist eine administrative Schnittstelle. Wer Zugriff darauf bekommt, kann Downloadaufträge steuern. Deshalb öffne ich Port 6800 nicht mehr mit ufw allow 6800 ins Internet.

Auch die WebUI braucht bei mir keinen öffentlichen Port. Für einen gelegentlichen administrativen Zugriff reicht ein SSH-Tunnel:

ssh -L 6880:127.0.0.1:6880 -L 6800:127.0.0.1:6800 user@server

Danach kann die WebUI lokal im Browser über http://127.0.0.1:6880 geöffnet werden. In der WebUI muss für die RPC-Verbindung das gleiche Secret eingetragen werden.

Updates

cd /opt/aria2
docker compose pull
docker compose up -d

Vor einem Update sollte man bei produktiv genutzten Downloads natürlich prüfen, ob die verwendete Container-Version oder Konfiguration Änderungen mitbringt.

Nextcloud: heute nicht mehr über ocDownloader


Der ursprüngliche Artikel war eng mit ocDownloader für Nextcloud verbunden. Diese Kombination empfehle ich heute nicht mehr. Für Nextcloud habe ich inzwischen modernere Lösungen im Blog, unter anderem meine eigene App MediaFetch.

Fazit


aria2 selbst ist weiterhin ein nützliches Werkzeug. Der entscheidende Unterschied zu meiner alten Installation ist die Absicherung: kein offener RPC-Port, kein öffentliches Webinterface und ein RPC-Secret. Genau solche Kleinigkeiten machen bei einem Server im Internet einen großen Unterschied.

Quellen: aria2-Projekt und Docker-Image mit WebUI.

This entry was edited (yesterday, 9:39 PM)

Docker-Container 2026 sicher aktualisieren: Compose, Diun und Renovate statt Watchtower


Docker-Updates 2026 kontrolliert verwalten: warum Watchtower archiviert ist, wie du mit Compose bewusst aktualisierst und Diun oder Renovate für Benachrichtigungen nutzt.

Überarbeitet am 8. September 2026.

Docker-Container automatisch zu aktualisieren klingt erstmal perfekt: neues Image verfügbar, Container wird neu erstellt, fertig. Genau deshalb habe ich früher Watchtower eingesetzt. Heute würde ich das auf einem produktiven Server deutlich vorsichtiger angehen.

Der wichtigste Grund: Das ursprüngliche Projekt containrrr/watchtower wurde am 17. Dezember 2025 archiviert und wird nicht mehr gepflegt. Meine alte Watchtower-Anleitung ist damit selbst zu einem guten Beispiel dafür geworden, warum Infrastruktur nicht blind jahrelang automatisch weiterlaufen sollte.

Mein heutiger Ansatz ist einfacher: Updates erkennen, kurz prüfen, Backup im Blick haben und dann mit Docker Compose bewusst aktualisieren. Wer mehr Automatisierung möchte, kann sich über neue Images benachrichtigen lassen oder Änderungen über Git verwalten.

Table of Contents
Toggle

Warum ich nicht mehr alles blind automatisch aktualisiere


Ein neues Container-Image ist nicht automatisch ein risikoloses Update. Es können sich Umgebungsvariablen ändern, Datenbankmigrationen nötig werden oder Konfigurationsoptionen verschwinden. Genau das haben wir beispielsweise bei Pi-hole v6 gesehen.

Wenn ein Update nachts automatisch durchläuft und danach Nextcloud, Mailcow oder eine Datenbank nicht mehr sauber startet, ist „immer aktuell“ plötzlich kein Vorteil mehr.

Variante 1: Docker Compose bewusst aktualisieren


Für meinen privaten Server ist das oft schon die beste Lösung. Im Verzeichnis des jeweiligen Compose-Projekts:
docker compose pull
docker compose up -d
docker compose ps
pull lädt die aktuellen Images der in der Compose-Datei verwendeten Tags. up -d erstellt betroffene Container bei Bedarf neu und lässt unveränderte Dienste in Ruhe.

Danach schaue ich kurz in die Logs:
docker compose logs --tail 100
Bei wichtigen Diensten teste ich zusätzlich die Anwendung selbst: Login funktioniert? Datenbank erreichbar? Upload oder Schreibzugriff okay? Erst dann ist das Update für mich wirklich erledigt.

Die Grundlagen zu diesen Befehlen findest du in Docker Compose erklärt und in Docker-Container für Einsteiger.

Nicht überall latest verwenden


Ein großer Teil der Update-Sicherheit beginnt schon in der compose.yaml. Statt überall nur latest einzutragen, kann man bei kritischen Diensten bewusst eine Haupt- oder konkrete Version verwenden.
image: mariadb:11.8Code-Sprache: CSS (css)
Damit entscheidet nicht irgendein zukünftiger Major-Sprung automatisch, wann die Datenbank auf eine völlig neue Generation wechselt.

Noch reproduzierbarer sind Images, die zusätzlich auf einen Digest festgelegt werden. Das ist vor allem interessant, wenn Compose-Dateien in Git liegen und Updates über Renovate verwaltet werden.

Variante 2: Diun meldet neue Images, aktualisiert aber nichts


Diun steht für Docker Image Update Notifier. Genau der Name beschreibt den Unterschied zu Watchtower ziemlich gut: Diun beobachtet Container-Images und benachrichtigt mich, wenn sich etwas geändert hat. Das eigentliche Update entscheide ich anschließend selbst.

Das gefällt mir für einen produktiven Homeserver deutlich besser als ein Dienst, der mit Zugriff auf den Docker-Socket eigenständig jeden Container ersetzt.

Ein kleines Diun-Compose-Beispiel

services:
diun:
image: crazymax/diun:latest
command: serve
restart: unless-stopped
volumes:
- ./data:/data
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
TZ: Europe/Berlin
DIUN_PROVIDERS_DOCKER: "true"
DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT: "false"
DIUN_WATCH_SCHEDULE: "0 */6 * * *"Code-Sprache: PHP (php)
In den Containern, die beobachtet werden sollen, wird anschließend ein Label gesetzt:
labels:
- "diun.enable=true"Code-Sprache: JavaScript (javascript)
Diun unterstützt verschiedene Benachrichtigungswege. Welche davon sinnvoll sind, hängt vom eigenen Setup ab. Der entscheidende Punkt für mich ist: Benachrichtigen und Aktualisieren sind zwei getrennte Schritte.

Achtung: Auch Diun braucht Zugriff auf Docker


Damit Diun laufende Container erkennen kann, benötigt der Docker-Provider Zugriff auf den Docker-Socket. Dieser Socket ist sicherheitstechnisch mächtig und sollte nicht gedankenlos an beliebige Container durchgereicht werden.

Ich würde deshalb nur vertrauenswürdige Images einsetzen und den Zugriff nicht als harmlose Kleinigkeit betrachten. Wer seine Compose-Dateien ohnehin in Git verwaltet, kann komplett auf diese lokale Docker-Erkennung verzichten und stattdessen Renovate verwenden.

Variante 3: Renovate aktualisiert die Compose-Datei per Pull Request


Renovate kann Docker-Images direkt in Compose-Dateien erkennen. Liegt meine Serverkonfiguration beispielsweise in einem privaten Git-Repository, kann Renovate bei einer neuen Version einen Pull Request erzeugen.

Das hat einen großen Vorteil: Ich sehe die Änderung, kann Release Notes prüfen und entscheide erst danach, ob sie übernommen wird. Das ist kontrollierter als ein nächtlicher Container-Tausch ohne Review.

Renovate unterstützt dabei auch Docker-Digests. Ein Image kann lesbar mit Tag eingetragen und gleichzeitig auf einen konkreten SHA256-Digest festgelegt werden. Renovate aktualisiert diesen Digest anschließend über einen Pull Request.
image: nginx:1.29-alpine@sha256:...Code-Sprache: HTTP (http)
Für einen einzelnen kleinen Server ist das vielleicht mehr GitOps als nötig. Wer seine Docker-Konfigurationen aber ohnehin versioniert, bekommt damit einen sehr nachvollziehbaren Updateprozess.

Was ich nicht mehr empfehlen würde: Ouroboros als Watchtower-Ersatz


In einer früheren Version dieses Artikels hatte ich Ouroboros als Alternative genannt. Das nehme ich wieder heraus. Nur weil ein Werkzeug einmal eine Watchtower-Alternative war, heißt das nicht, dass es Jahre später noch die beste Empfehlung ist.

Genau das ist übrigens auch der Grund, warum ich solche alten Infrastrukturartikel gerade Stück für Stück überarbeite.

Backups vor kritischen Updates


Container selbst sind schnell neu erstellt. Die wichtigen Dinge liegen aber in Datenbanken und Volumes. Vor einem größeren Update von Nextcloud, MariaDB, PostgreSQL oder einem anderen zustandsbehafteten Dienst möchte ich deshalb ein aktuelles Backup haben.

Für meine Serverdaten nutze ich unter anderem Borg. Die aktuelle Einrichtung habe ich hier beschrieben: BorgBackup unter Debian und Ubuntu einrichten.

Nach dem Update alte Images aufräumen


Wenn ein Update erfolgreich läuft und kein schneller Rollback auf das alte Image mehr nötig ist, sammeln sich mit der Zeit ungenutzte Images an.

Vor dem Löschen schaue ich zuerst:
docker image ls
Ungenutzte Images lassen sich später gezielt mit den normalen Docker-Prune-Funktionen bereinigen. Dabei sollte man genauso wenig blind löschen wie bei Volumes.

Mein heutiger Workflow


Für einen kleinen selbst gehosteten Server würde ich es heute ungefähr so halten:

  1. Neue Version erkennen – beispielsweise über Diun oder Renovate.
  2. Release Notes beziehungsweise Breaking Changes prüfen.
  3. Bei wichtigen Diensten Backup kontrollieren.
  4. docker compose pull ausführen.
  5. docker compose up -d ausführen.
  6. Status, Logs und die Anwendung selbst testen.
  7. Alte Images erst später aufräumen.

Das sind ein paar Schritte mehr als „Watchtower macht das nachts automatisch“. Dafür weiß ich am nächsten Morgen aber auch ziemlich genau, warum meine Dienste noch laufen.

Weiterführend: Diun-Dokumentation, Renovate für Docker Compose und die Docker-Compose-Dokumentation.

This entry was edited (yesterday, 9:22 PM)
in reply to CobraCommander

Raises rent, offers no additional value to the proposition. Pay it or vacate. By the way, rent has been raised across the board in the are, so fuck you. Coincidentally your paltry COLA raises that are below the actual cost of living do not compensate to match the rent hike.

Also, you can call any time, and they will return your call as soon as possible, or more likely never. Good luck to you, and don’t even dream of receiving your full security deposit back, as those door hinges and 5 year old carpet looks nothing like it did when you moved in and must be replaced.

Pi-hole v6 mit Docker Compose installieren – DNS-Werbeblocker im Heimnetz


Pi-hole v6 per Docker Compose installieren: aktuelle FTLCONF-Variablen, persistente Daten, sicheres Webpasswort, DNS im Heimnetz und Updates ohne offene Resolver-Falle.

Überarbeitet am 8. September 2026.

Pi-hole ist für mich nach wie vor eine der angenehmsten Möglichkeiten, Werbung und Tracking bereits auf DNS-Ebene für ein komplettes Heimnetz zu filtern. Meine alte Docker-Anleitung war allerdings dringend fällig: Sie verwendete noch ein uraltes Image, alte Umgebungsvariablen und war ursprünglich sogar auf einem öffentlich erreichbaren Root-Server entstanden.

Ganz wichtig: Einen Pi-hole-DNS-Server würde ich nicht offen ins Internet stellen. Port 53 gehört nur in das eigene LAN beziehungsweise in ein bewusst abgesichertes VPN. Ein öffentlicher rekursiver DNS-Resolver kann missbraucht werden und unnötig viel Traffic verursachen.

Falls Docker und Docker Compose noch fehlen, habe ich dafür eine aktuelle Anleitung: Docker und Docker Compose unter Debian und Ubuntu installieren.

Table of Contents
Toggle

Pi-hole v6: Was hat sich geändert?


Seit Pi-hole v6 sieht die Docker-Konfiguration deutlich anders aus. Fast alle alten Environment-Variablen aus v5 wurden durch die neuen FTLCONF_...-Variablen ersetzt.

Ein paar Beispiele:

  • WEBPASSWORDFTLCONF_webserver_api_password
  • DNSMASQ_LISTENINGFTLCONF_dns_listeningMode
  • PIHOLE_DNS_FTLCONF_dns_upstreams
  • DNSSECFTLCONF_dns_dnssec

Wer eine alte v5-Konfiguration übernimmt, sollte deshalb nicht einfach das Image aktualisieren und hoffen, dass alle alten Variablen weiter gelten.

1. Verzeichnis anlegen

sudo mkdir -p /opt/pihole/etc-pihole
sudo chown -R $USER:$USER /opt/pihole
cd /opt/piholeCode-Sprache: PHP (php)
Für eine neue Pi-hole-v6-Installation reicht normalerweise das persistente Verzeichnis /etc/pihole. Das früher häufig eingebundene /etc/dnsmasq.d ist laut aktueller Pi-hole-Dokumentation für einen frischen v6-Start normalerweise nicht mehr nötig.

2. Webpasswort in .env ablegen


Das Admin-Passwort schreibe ich nicht direkt in die compose.yml. Ein zufälliges Passwort lässt sich zum Beispiel so erzeugen:
openssl rand -base64 24
Danach:
nano /opt/pihole/.envPIHOLE_PASSWORD=DEIN_LANGES_ZUFAELLIGES_PASSWORTchmod 600 /opt/pihole/.env
Pi-hole unterstützt alternativ auch Docker Secrets über WEBPASSWORD_FILE. Für ein kleines privates Compose-Setup finde ich eine geschützte .env-Datei aber leichter nachvollziehbar.

3. compose.yml für Pi-hole v6


In diesem Beispiel hat der Docker-Host im Heimnetz die feste IP 192.168.178.10. Diese Adresse musst du durch die IP deines eigenen Servers ersetzen.
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
restart: unless-stopped
ports:
- "192.168.178.10:53:53/tcp"
- "192.168.178.10:53:53/udp"
- "192.168.178.10:8080:80/tcp"
environment:
TZ: "Europe/Berlin"
FTLCONF_webserver_api_password: "${PIHOLE_PASSWORD}"
FTLCONF_dns_listeningMode: "ALL"
FTLCONF_dns_upstreams: "9.9.9.9;149.112.112.112"
volumes:
- ./etc-pihole:/etc/piholeCode-Sprache: JavaScript (javascript)
Warum binde ich die Ports ausdrücklich an die LAN-IP? So lauscht der Container nicht automatisch auf sämtlichen Netzwerkschnittstellen des Hosts. Gerade auf einem Server mit mehreren Interfaces ist das wesentlich eindeutiger.

Die offiziellen Pi-hole-Beispiele veröffentlichen zusätzlich Port 443. Für einen einfachen Start im geschützten Heimnetz reicht mir hier zunächst die Weboberfläche auf Port 8080. Wer das Admin-Panel über HTTPS betreiben möchte, kann das anschließend bewusst ergänzen.

4. Pi-hole starten

cd /opt/pihole
docker compose up -d
docker compose ps
Bei Problemen sind die Logs meistens der schnellste Weg:
docker logs -f --tail 100 pihole
Das Admin-Panel ist im Beispiel anschließend erreichbar unter:
192.168.178.10:8080/admin/Code… JavaScript (javascript)

5. Pi-hole als DNS-Server im Heimnetz verteilen


Damit nicht jedes Smartphone und jeder Rechner einzeln konfiguriert werden muss, trage ich die Pi-hole-IP am liebsten im Router als lokalen DNS-Server ein. Dann erhalten die Clients den DNS-Server automatisch per DHCP.

Bei einer FRITZ!Box hängt der genaue Menüpunkt von FRITZ!OS ab. Wichtig ist am Ende nur: Die Clients sollen 192.168.178.10 als DNS-Server verwenden.

6. Funktion testen


Von einem Rechner im LAN kann man direkt prüfen, ob Pi-hole antwortet:
nslookup example.com 192.168.178.10Code-Sprache: CSS (css)
Unter Linux geht alternativ:
dig @192.168.178.10 example.comCode-Sprache: CSS (css)
Wenn eine Antwort kommt und die Anfrage kurz danach im Pi-hole Query Log auftaucht, funktioniert der grundlegende DNS-Weg.

7. Keine wahllosen Blocklisten sammeln


In der alten Anleitung hatte ich eine ganze Sammlung fremder Blocklisten direkt zum Kopieren aufgeführt. Das würde ich heute anders machen. Listen verschwinden, werden nicht mehr gepflegt oder blockieren irgendwann mehr als gewünscht.

Ich würde zunächst mit den vorhandenen Pi-hole-Listen starten und zusätzliche Quellen nur dann ergänzen, wenn ich einen konkreten Grund dafür habe. Lieber wenige gepflegte Listen als eine halbe Million Domains aus irgendwelchen alten GitHub-Repositories.

8. Pi-hole als DHCP-Server?


Das ist möglich, aber für einen Docker-Container etwas aufwendiger. Das offizielle Compose-Beispiel benötigt dafür unter anderem UDP-Port 67 und die Capability NET_ADMIN.

Wenn der vorhandene Router den Pi-hole-DNS-Server sauber per DHCP verteilen kann, würde ich DHCP zunächst dort lassen. Pi-hole als DHCP-Server würde ich erst einrichten, wenn dafür wirklich ein Grund besteht.

9. Pi-hole aktualisieren


Im Docker-Container verwendet man nicht pihole -up. Pi-hole weist ausdrücklich darauf hin, dass Docker-Installationen über ein neues Container-Image aktualisiert werden:
cd /opt/pihole
docker compose pull
docker compose down
docker compose up -d
Die Konfiguration bleibt durch das Volume ./etc-pihole:/etc/pihole erhalten.

Vor größeren Versionssprüngen lohnt sich trotzdem immer ein Blick in die Release Notes. Gerade der Wechsel von Pi-hole v5 auf v6 hat gezeigt, dass sich Environment-Variablen ändern können.

Mein Fazit


Pi-hole im Docker-Container ist 2026 weiterhin unkompliziert – wenn man nicht versucht, eine fünf Jahre alte Compose-Datei unverändert weiterzuverwenden. Für mich sind die wichtigsten Punkte: aktuelle FTLCONF_-Variablen, persistente Daten, ein ordentliches Admin-Passwort und DNS-Port 53 niemals versehentlich öffentlich ins Internet stellen.

Aktuelle Beispiele findest du in der offiziellen Pi-hole-Docker-Dokumentation und in der Migrationsübersicht von v5 auf v6.

This entry was edited (yesterday, 9:13 PM)

ONLYOFFICE Docs mit Docker Compose und Nextcloud einrichten – sicher hinter Nginx


ONLYOFFICE Document Server per Docker Compose einrichten: localhost-Port, JWT-Secret, Nginx-Reverse-Proxy, HTTPS und Nextcloud-Connector sauber konfigurieren.

Überarbeitet am 8. September 2026.

ONLYOFFICE Docs ist weiterhin eine interessante Möglichkeit, Office-Dateien direkt in Nextcloud im Browser zu bearbeiten. Der Nextcloud-Connector wird aktiv gepflegt und unterstützt im September 2026 Nextcloud bis Version 34. Meine alte Anleitung funktioniert in Teilen noch, enthält aber inzwischen ein paar Dinge, die ich so nicht mehr empfehlen würde.

Vor allem würde ich den Document Server heute nicht mehr mit einem offenen Port ins Internet stellen. Stattdessen binde ich ihn nur an 127.0.0.1 und lasse den öffentlichen Zugriff ausschließlich über Nginx und HTTPS laufen.

Falls Docker und das Compose-Plugin noch fehlen, findest du die aktuelle Installation in meiner Anleitung Docker und Docker Compose unter Debian und Ubuntu installieren.

Table of Contents
Toggle

1. Verzeichnis für ONLYOFFICE anlegen

sudo mkdir -p /opt/onlyoffice/{data,logs,lib}
sudo chown -R $USER:$USER /opt/onlyoffice
cd /opt/onlyofficeCode-Sprache: PHP (php)
Die zusätzlichen Verzeichnisse sind nicht zwingend nötig, damit der Container überhaupt läuft. Sie machen Logs und relevante Anwendungsdaten aber leichter zugänglich und verhindern, dass alles ausschließlich im Container liegt.

2. Starkes JWT-Secret erzeugen


Seit ONLYOFFICE Docs 7.2 ist JWT standardmäßig aktiv. Wird kein eigenes Secret gesetzt, generiert ONLYOFFICE einen zufälligen Wert. Für eine feste Nextcloud-Integration ist ein eigenes Secret wesentlich praktischer, weil Nextcloud und Document Server denselben Schlüssel verwenden müssen.

Ein starkes Secret lässt sich so erzeugen:
openssl rand -hex 32
Den ausgegebenen Wert speichere ich in einer .env-Datei:
nano /opt/onlyoffice/.envJWT_SECRET=HIER_DEIN_LANGES_ZUFAELLIGES_SECRET
Danach die Datei nur für den Eigentümer lesbar machen:
chmod 600 /opt/onlyoffice/.env

3. compose.yml erstellen


Eine Versionsangabe wie version: '2.2' ist bei aktuellem Docker Compose nicht mehr nötig. Meine compose.yml sieht so aus:
services:
documentserver:
image: onlyoffice/documentserver:latest
container_name: onlyoffice-documentserver
restart: unless-stopped
ports:
- "127.0.0.1:8833:80"
environment:
JWT_ENABLED: "true"
JWT_SECRET: "${JWT_SECRET}"
volumes:
- ./data:/var/www/onlyoffice/Data
- ./logs:/var/log/onlyoffice
- ./lib:/var/lib/onlyofficeCode-Sprache: JavaScript (javascript)
Der entscheidende Unterschied zu meiner alten Anleitung ist diese Zeile:
127.0.0.1:8833:80Code-Sprache: CSS (css)
Damit lauscht Port 8833 nur auf dem lokalen Host. Ein ufw allow 8833 ist dadurch weder nötig noch gewünscht. Von außen soll ausschließlich Nginx auf Port 443 erreichbar sein.

Hinweis zu latest: Für einen privaten Testserver ist das bequem. Auf einem produktiven System würde ich eher eine zuvor getestete ONLYOFFICE-Version fest pinnen und Updates bewusst durchführen.

4. Container starten und prüfen

cd /opt/onlyoffice
docker compose up -d
docker compose ps
Falls der Container nicht sauber startet, helfen die Logs:
docker logs -f --tail 100 onlyoffice-documentserver
Vom Host aus kann man außerdem testen, ob der Dienst antwortet:
curl -I 127.0.0.1:8833/Code-Sprache: JavaScript (javascript)

5. Nginx als Reverse Proxy einrichten


ONLYOFFICE benötigt hinter einem Proxy unter anderem die korrekten X-Forwarded-Proto– und X-Forwarded-Host-Header. Auch WebSocket-Verbindungen müssen weitergereicht werden.

Die Map für WebSocket-Verbindungen gehört in den http-Kontext von Nginx, beispielsweise in eine Datei unter /etc/nginx/conf.d/:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}Code-Sprache: PHP (php)
Der eigentliche Virtual Host kann anschließend beispielsweise so aussehen. Die Zertifikatspfade musst du natürlich an deine Domain anpassen:
server {
listen 80;
server_name office.example.de;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl;
server_name office.example.de;

ssl_certificate /etc/letsencrypt/live/office.example.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/office.example.de/privkey.pem;

client_max_body_size 100M;

location / {
proxy_pass 127.0.0.1:8833;
proxy_http_version 1.1;

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

proxy_read_timeout 3600s;
}
}Code-Sprache: PHP (php)
Die uralte TLS-1.0/1.1- und Cipher-Liste aus meiner früheren Anleitung habe ich bewusst entfernt. TLS-Einstellungen sollten heute zentral und passend zur verwendeten Nginx-Version gepflegt werden, statt jahrelang einen alten Cipher-Block aus einem Blogartikel mitzuschleppen.

Danach wie immer testen und neu laden:
sudo nginx -t
sudo systemctl reload nginx

6. ONLYOFFICE-App in Nextcloud installieren


In Nextcloud wird anschließend die App ONLYOFFICE aus dem App Store installiert. Der Connector unterstützt aktuell Nextcloud bis Version 34.

Unter den ONLYOFFICE-Einstellungen trägst du als Document-Server-Adresse ein:
office.example.de/Code-Sprache… JavaScript (javascript)
Im Feld für den geheimen Schlüssel kommt derselbe JWT-Wert hinein, der in der .env-Datei des Document Servers steht.

7. Wenn öffentliche Adressen intern nicht funktionieren


In manchen Docker- oder Firewall-Setups können Nextcloud und ONLYOFFICE ihre öffentlichen Domains intern nicht erreichen. Dafür bietet der Connector unter den erweiterten Servereinstellungen getrennte interne Adressen an.

Diese Felder würde ich nur verwenden, wenn sie wirklich benötigt werden. In einer normalen Installation, in der beide Seiten ihre öffentlichen HTTPS-Adressen erreichen können, ist das nicht nötig.

8. Verbindung testen


Nach dem Speichern der Einstellungen lege ich in Nextcloud eine kleine DOCX-Datei an beziehungsweise öffne eine vorhandene Datei. Wenn der Editor erscheint und Änderungen gespeichert werden, funktioniert die grundlegende Integration.

Wenn Nextcloud stattdessen einen Verbindungsfehler zeigt, prüfe ich in dieser Reihenfolge:

  • Ist docker compose ps grün?
  • Antwortet curl http://127.0.0.1:8833/ lokal?
  • Ist https://office.example.de öffentlich erreichbar?
  • Ist das Zertifikat gültig?
  • Stimmt das JWT-Secret auf beiden Seiten exakt überein?
  • Kann ONLYOFFICE die Nextcloud-Adresse selbst erreichen?


9. Updates bewusst durchführen

cd /opt/onlyoffice
docker compose pull
docker compose up -d
Auf einem produktiven System würde ich Document Server und Nextcloud-Connector nicht blind automatisch aktualisieren. Gerade bei Office-Integrationen lohnt es sich, vor einem Versionssprung kurz die Kompatibilität zu prüfen und die Konfiguration zu sichern.

ONLYOFFICE oder Collabora?


Beide Lösungen funktionieren mit Nextcloud und haben ihre eigenen Stärken. Wenn du statt ONLYOFFICE lieber die LibreOffice-nahe Variante einsetzen möchtest, habe ich auch die Anleitung Nextcloud Office mit Collabora einrichten aktualisiert.

Weiterführend: ONLYOFFICE Docs per Docker installieren, ONLYOFFICE mit Nextcloud verbinden und ONLYOFFICE hinter einem Reverse Proxy.


Nextcloud Office mit Collabora einrichten: Docker, Reverse Proxy und Tests


Überarbeitet am 8. September 2026.

Diese Anleitung ist einer der Artikel, bei denen das Alter besonders deutlich geworden ist. Meine ursprüngliche Version brauchte noch einen speziellen Ubuntu-16.04-Kernel und hantierte mit AUFS. Das ist heute Geschichte. Nextcloud Office basiert weiterhin auf Collabora Online beziehungsweise CODE, lässt sich aber inzwischen wesentlich entspannter einrichten.

Für kleine private Installationen gibt es sogar einen eingebauten CODE-Server. Wer etwas mehr Leistung möchte, betreibt Collabora separat – zum Beispiel als Docker-Container hinter einem Reverse Proxy. Genau diesen Weg zeige ich hier.

Falls Docker auf deinem Server noch fehlt, findest du hier meine aktualisierte Anleitung: Docker und Docker Compose unter Debian und Ubuntu installieren.

Table of Contents
Toggle

Was ist Nextcloud Office eigentlich?


Nextcloud Office ist die Office-Integration innerhalb von Nextcloud. Die eigentliche Bearbeitung übernimmt Collabora Online. Damit lassen sich unter anderem DOCX-, XLSX-, PPTX- und OpenDocument-Dateien direkt im Browser öffnen und gemeinsam bearbeiten.

Wenn du erstmal nur ausprobieren möchtest, ob dir das gefällt, reicht für eine kleine Installation oft der Built-in CODE Server. Er lässt sich als Nextcloud-App installieren und funktioniert in vielen Setups ohne zusätzlichen Container. Nextcloud weist allerdings selbst darauf hin, dass ein separater Collabora-Server für bessere Performance sinnvoller ist.

1. Eigene Subdomain für Collabora vorbereiten


Für einen separaten Collabora-Server würde ich eine eigene Subdomain verwenden, zum Beispiel:
office.example.deCode-Sprache: CSS (css)
Die Subdomain zeigt auf deinen Server und bekommt ein gültiges TLS-Zertifikat. Auch deine Nextcloud sollte natürlich über HTTPS erreichbar sein. Nextcloud und Collabora sollten dasselbe Protokoll verwenden – praktisch also beide HTTPS.

Mehr zu den grundlegenden Sicherheitsmaßnahmen findest du in Nextcloud richtig absichern.

2. Collabora CODE als Docker-Container starten


Das offizielle CODE-Image heißt weiterhin collabora/code. Zuerst laden wir es:
docker pull collabora/code
Danach starten wir Collabora nur auf localhost. So ist Port 9980 nicht direkt aus dem Internet erreichbar:
docker run -t -d \
-p 127.0.0.1:9980:9980 \
-e 'aliasgroup1=https://cloud.example.de:443' \
--restart always \
--cap-add MKNOD \
--name collabora \
collabora/codeCode-Sprache: JavaScript (javascript)
cloud.example.de ersetzt du durch die Domain deiner Nextcloud. Der Container lauscht anschließend nur auf 127.0.0.1:9980. Von außen kommt man später ausschließlich über den Reverse Proxy an Collabora heran.

3. Reverse Proxy vor Collabora setzen


Collabora benötigt einen Reverse Proxy, der die öffentliche Adresse https://office.example.de auf den lokalen Dienst an Port 9980 weiterleitet. Anders als in sehr alten Anleitungen heißen die wichtigen Pfade heute unter anderem:

  • /browser
  • /hosting/discovery
  • /hosting/capabilities
  • /cool
  • WebSocket-Verbindungen unter /cool/.../ws

Wer noch eine alte Konfiguration mit /lool und /loleaflet hat, sollte sie deshalb überprüfen. Die aktuellen Collabora-Komponenten verwenden coolwsd, /cool und /browser.

Da ich selbst Nginx nutze, würde ich dafür die aktuelle Reverse-Proxy-Vorlage von Collabora beziehungsweise Nextcloud als Ausgangspunkt nehmen. Besonders wichtig ist, dass die WebSocket-Verbindung mit durchgereicht wird. Eine reine normale HTTP-Weiterleitung reicht nicht.

4. Erst Collabora testen


Bevor ich Nextcloud konfiguriere, teste ich den Office-Server separat. Diese beiden Adressen sollten über den Browser erreichbar sein:
office.example.de/hosting/capa…
office.example.de/hosting/disc… JavaScript (javascript)
Auch direkt vom Nextcloud-Server aus kann man testen:
curl office.example.de/hosting/capa…
curl office.example.de/hosting/disc… JavaScript (javascript)
Wenn das schon nicht funktioniert, braucht man in Nextcloud noch gar nicht weiterzusuchen. Dann liegt das Problem eher bei DNS, Zertifikat, Firewall oder Reverse Proxy.

5. Nextcloud Office installieren und verbinden


In Nextcloud gehst du zu Apps → Office & Text und installierst beziehungsweise aktivierst Nextcloud Office.

Anschließend findest du unter Administrationseinstellungen → Office die Verbindung zum Collabora-Server. Dort trägst du ein:
office.example.deCode-Sprache: JavaScript (javascript)
Wenn alles stimmt, sollte Nextcloud die Verbindung erkennen. Danach kannst du direkt eine neue Textdatei oder Tabelle erstellen und testen.

6. WOPI-Zugriffe einschränken


Ein Punkt, den es in meiner alten Anleitung noch gar nicht gab: Nextcloud empfiehlt ausdrücklich, WOPI-Anfragen auf die erwarteten Collabora-Server zu begrenzen. Die entsprechende Allow-Liste findest du in den Office-Administrationseinstellungen.

Dort sollte möglichst nur die IP beziehungsweise das Netz eingetragen werden, aus dem dein Collabora-Server Nextcloud tatsächlich erreicht. Das verhindert, dass beliebige andere Systeme WOPI-Anfragen an deine Nextcloud stellen können.

7. Typische Fehler


Wenn Nextcloud Office nicht verbindet, prüfe ich in dieser Reihenfolge:

  • Kann der Browser Nextcloud und Collabora über HTTPS erreichen?
  • Kann Nextcloud office.example.de erreichen?
  • Kann Collabora wiederum die Nextcloud-Domain erreichen?
  • Ist das TLS-Zertifikat gültig?
  • Werden die /cool-WebSockets vom Reverse Proxy korrekt weitergeleitet?
  • Ist die WOPI-Allow-Liste korrekt?

Für den Container selbst helfen die Logs:
docker logs --tail 100 collabora
Die Nextcloud-Logs sollte man parallel ebenfalls ansehen. Sehr häufig ist es kein Office-Fehler, sondern schlicht eine nicht funktionierende Verbindung in eine der beiden Richtungen.

8. Collabora aktualisieren


Da CODE regelmäßig aktualisiert wird, sollte auch der Container nicht jahrelang unangetastet bleiben:
docker pull collabora/code
Anschließend wird der Container mit demselben Startbefehl neu erstellt. Wer stattdessen Docker Compose verwendet, kann das entsprechend mit docker compose pull und docker compose up -d erledigen.

Mein Fazit nach der Überarbeitung


Der Unterschied zu meiner ersten Collabora-Anleitung ist schon ziemlich absurd: Kein Xenial-Proposed, kein Kernel 4.4, kein AUFS-Gefrickel mehr. Für kleine Instanzen reicht heute sogar der eingebaute CODE-Server. Wer es etwas sauberer und performanter möchte, stellt einen separaten Collabora-Container hinter eine eigene HTTPS-Subdomain.

Wenn du noch am Anfang mit Nextcloud bist, findest du in Was bietet Nextcloud 2026? einen Überblick darüber, was die Cloud inzwischen alles kann.

Weiterführend: Nextcloud Office installieren, Collabora per Docker und Troubleshooting.


This entry was edited (yesterday, 9:12 PM)

Brother MFC-J4625DW unter Linux installieren: Drucker und Scanner einrichten


Brother MFC-J4625DW unter Debian/Ubuntu installieren: aktuelles Driver Install Tool, CUPS-Drucker, Scanner-Treiber und Netzwerk-Scanner sauber einrichten.

Überarbeitet am 8. September 2026.

Der Brother MFC-J4625DW ist inzwischen kein neues Gerät mehr, aber genau deshalb wollte ich diese Anleitung nicht einfach löschen. Brother bietet für das Modell auch 2026 noch offizielle Linux-Downloads für DEB- und RPM-Systeme an. Die alte Anleitung war allerdings mit vielen Paketnamen, 32-Bit-Resten und manuellen Schritten ziemlich unübersichtlich geworden.

Ich konzentriere mich hier deshalb auf Debian- und Ubuntu-basierte Systeme. Für Arch Linux beziehungsweise Garuda stellt Brother auf der offiziellen Downloadseite keine eigenen Arch-Pakete bereit.

Table of Contents
Toggle

1. Erst prüfen, ob Linux den Drucker schon erkennt


Bevor ich zusätzliche Treiber installiere, würde ich den Drucker zunächst über USB oder Netzwerk verbinden und prüfen, ob CUPS ihn bereits automatisch findet. Bei manchen Distributionen funktioniert Drucken heute direkt über vorhandene Treiber beziehungsweise treiberlose Druckverfahren.

Wenn Drucken funktioniert, der Scanner aber fehlt, muss nicht zwangsläufig das komplette Brother-Paket neu installiert werden.

2. Offizielle Brother-Downloadseite verwenden


Brother führt für den MFC-J4625DW weiterhin Linux (deb) und Linux (rpm) als Betriebssysteme. Für Debian, Ubuntu, Linux Mint und ähnliche Systeme ist die DEB-Variante normalerweise die passende Wahl.

Am bequemsten ist das von Brother angebotene Driver Install Tool. Laut Brother installiert es LPR-, CUPS-Wrapper- und bei Multifunktionsgeräten auch Scanner-Treiber. Das Tool wurde für dieses Modell zuletzt im September 2025 aktualisiert.

Download: Brother Support für den MFC-J4625DW.

3. Driver Install Tool ausführen


Nach dem Download liegt normalerweise eine komprimierte Datei im Download-Ordner. Der genaue Dateiname kann sich mit neuen Versionen ändern. Deshalb verwende ich hier bewusst Platzhalter statt einer fest verdrahteten Versionsnummer.
cd ~/Downloads
gunzip linux-brprinter-installer-*.gz
chmod +x linux-brprinter-installer-*
sudo ./linux-brprinter-installer-* MFC-J4625DW
Die Rückfragen des Installers hängen davon ab, ob der Drucker per USB oder Netzwerk verbunden ist. Bei einem Netzwerkdrucker sollte die IP-Adresse des Geräts bekannt sein beziehungsweise möglichst fest vergeben werden.

4. Prüfen, ob CUPS den Drucker kennt

lpstat -p -d
Wenn der Drucker dort auftaucht, würde ich direkt eine Testseite drucken. Bei Problemen lohnt sich zusätzlich ein Blick in die CUPS-Weboberfläche unter http://localhost:631, sofern sie auf dem System aktiviert ist.

5. Scanner prüfen


Brother bietet für dieses Modell weiterhin einen 64-Bit-DEB-Scannertreiber an. Die aktuelle Supportseite führt dafür brscan4-basierte Pakete.

Nach der Installation kann man zuerst prüfen, ob SANE das Gerät findet:
scanimage -L
Wenn dort ein Scanner erscheint, sollten Programme wie Document Scanner beziehungsweise Simple Scan oder gscan2pdf ebenfalls darauf zugreifen können.

6. Netzwerk-Scanner manuell eintragen


Wird der Drucker über das Netzwerk gefunden, der Scanner aber nicht, kann bei brscan4-Geräten ein manueller Eintrag helfen:
sudo brsaneconfig4 -a name=MFC-J4625DW model=MFC-J4625DW ip=192.168.1.50
Die IP-Adresse musst du natürlich durch die Adresse deines Druckers ersetzen. Danach erneut testen:
scanimage -L

7. Scan-Key-Funktion ist ein eigenes Paket


Wer direkt am Brother-Gerät die Taste „Scan to PC“ verwenden möchte, benötigt zusätzlich das Scan-Key-Tool. Interessanterweise stellt Brother dafür auch 2026 noch aktualisierte Linux-Pakete bereit. Für reines Scannen aus einer Linux-Anwendung ist dieses Zusatzpaket nicht zwingend nötig.

Und unter Arch Linux oder Garuda?


Brother selbst bietet für dieses Modell offiziell DEB- und RPM-Pakete an, aber keine nativen Arch-Pakete. Unter Arch/Garuda würde ich deshalb zuerst prüfen, ob Drucken über CUPS beziehungsweise treiberlos funktioniert. Für Herstellertreiber gibt es teilweise Community-/AUR-Pakete, deren Aktualität aber separat geprüft werden sollte.

Mein Fazit


Der MFC-J4625DW ist alt, aber unter Linux keineswegs unbrauchbar. Dass Brother selbst 2026 noch das Driver Install Tool, Scanner-Pakete und sogar ein aktualisiertes Scan-Key-Tool anbietet, ist für so ein älteres Multifunktionsgerät ziemlich angenehm. Ich würde heute nur nicht mehr jedes einzelne Paket manuell zusammensuchen, sondern zuerst den offiziellen Installer verwenden und danach gezielt den Scanner prüfen.

This entry was edited (yesterday, 9:00 PM)

Nextcloud Desktop und getaktete Verbindung: Synchronisierung 2026 weiterhin beachten


Nextcloud Desktop kann weiterhin nicht automatisch auf getaktete Verbindungen reagieren. So vermeidest du ungewollten Sync über Smartphone-Hotspot oder mobiles Datenvolumen.

Überarbeitet am 8. September 2026.

Manchmal überlebt ein alter Blogartikel erstaunlich lange. Diesen hier hatte ich ursprünglich 2020 geschrieben, weil der Nextcloud-Desktop-Client eine getaktete Verbindung unter Windows nicht automatisch berücksichtigt. Ich hätte ehrlich gesagt erwartet, dass das Thema inzwischen erledigt ist.

Ist es aber nicht. Das zugehörige GitHub-Issue #39 „Stop Sync on mobile connection“ stammt aus November 2017 und ist im September 2026 weiterhin offen. Es ist als bestätigtes Thema markiert, steht laut Projekt aber derzeit nicht auf der Roadmap.

Table of Contents
Toggle

Warum das überhaupt wichtig ist


Wer den Laptop unterwegs über den Smartphone-Hotspot ins Internet bringt, möchte normalerweise nicht, dass im Hintergrund plötzlich mehrere Gigabyte Nextcloud-Daten synchronisiert werden.

Windows kann WLAN-Verbindungen selbst als getaktete Verbindung kennzeichnen. Viele Programme reduzieren dann automatisch ihren Datenverkehr. Der Nextcloud-Desktop-Client nutzt diese Information bislang aber nicht zuverlässig als automatische Sync-Sperre.

Vor dem Hotspot: Synchronisierung pausieren


Die einfachste Lösung ist deshalb weiterhin ziemlich banal: Bevor ich mich mit einem mobilen Hotspot verbinde, pausiere ich die Nextcloud-Synchronisierung manuell.

Nach dem Wechsel zurück ins normale WLAN oder LAN kann die Synchronisierung wieder aktiviert werden.

Windows-Verbindung trotzdem als getaktet markieren


Auch wenn Nextcloud selbst die Einstellung nicht automatisch auswertet, würde ich einen Smartphone-Hotspot unter Windows trotzdem als getaktet konfigurieren. Andere Windows-Dienste und Programme können dadurch ihren Hintergrundverkehr reduzieren.

Große Ordner bewusst auswählen


Wer häufig mobil arbeitet, sollte außerdem überlegen, ob wirklich die komplette Nextcloud lokal synchronisiert werden muss. Große Foto-, Video- oder Backup-Verzeichnisse brauche ich unterwegs normalerweise nicht ständig auf dem Notebook.

Eine schlankere Synchronisationsauswahl reduziert nicht nur mobilen Datenverbrauch, sondern spart auch lokalen Speicherplatz.

Ein überraschend langlebiges Feature-Request


Dass dieses Thema nach so vielen Jahren noch offen ist, hätte ich beim Schreiben der ursprünglichen Version wirklich nicht erwartet. Wer die Funktion ebenfalls vermisst, kann den aktuellen Stand im GitHub-Issue verfolgen.

Mehr rund um meine eigene Cloud findest du auch in Was bietet Nextcloud 2026? und in meiner Anleitung Nextcloud richtig absichern.

Aktueller Stand des Feature-Requests: Nextcloud Desktop Issue #39.


Was bietet Nextcloud 2026? Mehr als nur eine private Cloud


Überarbeitet am 8. September 2026.

Als ich Nextcloud vor Jahren zum ersten Mal installiert habe, war mein Hauptgedanke ziemlich simpel: Ich wollte meine Dateien nicht bei Google Drive oder einem anderen großen Cloud-Anbieter ablegen. Inzwischen ist daraus deutlich mehr geworden. Nextcloud ist heute eher ein kompletter digitaler Arbeitsplatz, den man auf dem eigenen Server betreiben kann.

Das Schöne daran: Man muss nicht alle Funktionen benutzen. Wer nur Dateien synchronisieren möchte, kann genau das tun. Wer später Kalender, Kontakte, Videochat, Office oder einen RSS-Reader ergänzen möchte, installiert die passenden Apps dazu.

Table of Contents
Toggle

Dateien synchronisieren und teilen


Der Kern von Nextcloud ist weiterhin Nextcloud Files. Dateien können über den Browser, Desktop-Clients und die Apps für Smartphones erreicht und synchronisiert werden. Damit bekommt man im Alltag etwas Ähnliches wie Dropbox, OneDrive oder Google Drive – nur eben auf dem eigenen Server oder bei einem selbst gewählten Anbieter.

Dateien und Ordner lassen sich außerdem per Link teilen. Solche Freigaben können je nach Bedarf mit Passwort, Ablaufdatum und weiteren Einschränkungen versehen werden. Auch Freigaben zwischen Nextcloud-Servern sind möglich.

Kalender und Kontakte


Kalender und Kontakte gehören für mich zu den Funktionen, die eine eigene Cloud erst richtig nützlich machen. Nextcloud verwendet dafür offene Standards wie CalDAV und CardDAV. Dadurch lassen sich Kalender und Adressbücher mit vielen Programmen und Betriebssystemen synchronisieren.

Damit liegt nicht nur die Dateiablage auf dem eigenen Server, sondern auf Wunsch auch das persönliche Adressbuch und der Kalender.

Nextcloud Talk für Chat und Videotelefonie


Mit Nextcloud Talk gibt es Chats, Sprach- und Videoanrufe direkt innerhalb der eigenen Nextcloud. Das funktioniert im Browser und über mobile Apps. Gerade für kleine Teams, Familien oder Vereine ist das interessant, weil Dateien und Gespräche nicht auf mehrere Plattformen verteilt werden müssen.

Dokumente direkt im Browser bearbeiten


Auch Office gehört inzwischen fest zum Nextcloud-Ökosystem. Dokumente, Tabellen und Präsentationen können direkt im Browser bearbeitet und gemeinsam genutzt werden. Welche Office-Lösung zum Einsatz kommt, hängt von der eigenen Installation ab.

Für mich ist genau das einer der Punkte, an denen Nextcloud über eine reine Dateiablage hinausgeht: Eine Datei muss nicht erst heruntergeladen, lokal bearbeitet und anschließend wieder hochgeladen werden.

Fotos und Videos


Fotos vom Smartphone können automatisch zur Nextcloud hochgeladen werden. Für die Anzeige gibt es die integrierten Funktionen von Nextcloud sowie zusätzliche Apps aus dem App Store. Gerade bei großen Fotosammlungen lohnt es sich, unterschiedliche Lösungen auszuprobieren, weil die Anforderungen sehr verschieden sein können.

Notizen, Aufgaben, Projekte und RSS


Der Nextcloud App Store ist für mich einer der größten Vorteile. Dort findet man Erweiterungen für sehr unterschiedliche Einsatzzwecke. Beispiele sind:

  • Notes für einfache Notizen
  • Tasks für Aufgaben
  • Deck für Kanban-Boards und Projektplanung
  • News als RSS-Feedreader
  • Mail für E-Mail
  • Bookmarks für Lesezeichen
  • External Storage für zusätzliche Speicherziele

Man sollte trotzdem nicht jeden Fund aus dem App Store installieren. Weniger ist bei einer produktiven Nextcloud oft mehr. Ich schaue vorher, ob eine App aktiv gepflegt wird und zur verwendeten Nextcloud-Version passt.

Versionierung und Papierkorb


Nextcloud kann ältere Dateiversionen aufbewahren und gelöschte Dateien zunächst im Papierkorb behalten. Das ersetzt natürlich kein richtiges Backup, ist im Alltag aber enorm praktisch. Eine Datei versehentlich überschrieben oder gelöscht? Oft lässt sie sich mit wenigen Klicks zurückholen.

Nextcloud ist keine automatische Datensicherung


Das ist ein Punkt, den ich heute deutlicher schreiben würde als früher: Nur weil Dateien in Nextcloud liegen, sind sie noch nicht automatisch sicher. Wird der Server beschädigt, verschlüsselt oder versehentlich gelöscht, kann auch die Cloud weg sein.

Zu einer selbst gehosteten Nextcloud gehört deshalb ein externes Backup der Daten, der Datenbank und der Konfiguration. Wer die Cloud selbst betreibt, bekommt Kontrolle – übernimmt dafür aber eben auch Verantwortung.

Datenschutz und Kontrolle als größter Vorteil


Der für mich wichtigste Unterschied zu vielen klassischen Cloud-Diensten ist bis heute derselbe: Ich entscheide, wo die Daten liegen. Bei einem eigenen Server kenne ich den Speicherort, kann Backups selbst organisieren und bestimme, welche Erweiterungen installiert werden.

Natürlich bedeutet das auch Arbeit. Updates, Backups und Sicherheit gehören dazu. Wer damit gar nichts zu tun haben möchte, kann Nextcloud auch bei einem Anbieter mieten und muss den Server nicht selbst administrieren.

Für wen lohnt sich Nextcloud?


Nextcloud lohnt sich aus meiner Sicht besonders für Leute, die ihre Daten nicht auf mehrere Dienste verteilen möchten. Dateien bei Anbieter A, Kalender bei B, Kontakte bei C und Videotelefonie bei D – das kann Nextcloud zumindest teilweise unter einem Dach zusammenführen.

Man muss dafür kein Unternehmen sein. Auch für eine einzelne Person oder eine Familie kann eine kleine Nextcloud sinnvoll sein. Und wer Spaß am Selfhosting hat, findet im App-Ökosystem ziemlich schnell das nächste Projekt.

Wenn du Nextcloud selbst betreibst, solltest du dir auch meinen aktualisierten Beitrag Nextcloud richtig absichern ansehen.

Mehr Informationen gibt es direkt bei Nextcloud und im Nextcloud App Store.


This entry was edited (yesterday, 8:58 PM)

Nextcloud News 2026: RSS-Feeds synchronisieren und passende Clients nutzen


Nextcloud News als eigener RSS-Reader: Feeds zentral speichern und mit RSS Guard, Fiery Feeds, Android-Clients oder Newsboat synchronisieren.

Überarbeitet am 8. September 2026.

RSS gehört für mich immer noch zu den angenehmsten Wegen, Nachrichten und Blogs zu verfolgen. Keine fünfzig einzelnen Apps, keine algorithmische Timeline – ich entscheide selbst, welche Quellen ich lesen möchte.

Wenn sowieso eine eigene Nextcloud läuft, liegt es nahe, die Feed-Abos dort zentral zu speichern. Genau dafür gibt es die App Nextcloud News. Die wird auch 2026 aktiv gepflegt und bietet neben der Weboberfläche eine API, über die externe Reader die Feeds, gelesenen Artikel und Markierungen synchronisieren können.

Wer noch einen allgemeinen Überblick über die Möglichkeiten der Plattform sucht: Was bietet Nextcloud 2026?

Table of Contents
Toggle

Nextcloud News installieren


Die App lässt sich direkt über den Nextcloud App Store installieren. Danach erscheint News in der App-Leiste und Feeds können über ihre RSS- oder Atom-Adresse hinzugefügt werden.

Die eigentliche Stärke ist für mich aber die Synchronisierung mit externen Readern. Dadurch bleibt Nextcloud die zentrale Datenbasis, während ich auf jedem Gerät die Oberfläche nutzen kann, die mir am besten gefällt.

Desktop: RSS Guard


Für Windows, Linux und macOS ist RSS Guard weiterhin eine der interessantesten Optionen. Die offizielle Nextcloud-News-Dokumentation führt RSS Guard als empfohlenen Desktop-Client.

Damit bekommt man einen klassischen Desktop-Feedreader, während gelesene Artikel und Abos mit Nextcloud News synchronisiert werden.

iPhone und Mac: Fiery Feeds


Mein alter Artikel drehte sich fast ausschließlich um Fiery Feeds. Die App existiert weiterhin und wird auch in der aktuellen Client-Liste von Nextcloud News für iOS und macOS aufgeführt.

Ich würde den Artikel heute aber nicht mehr auf genau eine App reduzieren. Der große Vorteil von Nextcloud News ist ja gerade, dass der Server unabhängig vom verwendeten Reader bleibt.

Android: Nextcloud News Reader und Readrops


Unter Android ist die Auswahl größer. Die Nextcloud-News-Dokumentation empfiehlt den Nextcloud News Reader und führt zusätzlich Readrops als kompatiblen Sync-Client auf.

Linux-Terminal: Newsboat


Wer viel im Terminal arbeitet, kann sogar Newsboat verwenden. Auch dieser Client wird von der Nextcloud-News-Dokumentation gelistet. Das ist vielleicht etwas nerdiger, aber genau solche Möglichkeiten mag ich an offenen Schnittstellen.

Weitere Desktop-Clients


Neben RSS Guard nennt die aktuelle Dokumentation unter anderem Fluent Reader, Communique und NewsFlash. Wichtig ist immer, dass der Client ausdrücklich die Nextcloud-News-API unterstützt – ein beliebiger RSS-Reader kann nicht automatisch mit der eigenen Nextcloud synchronisieren.

Warum überhaupt über Nextcloud synchronisieren?


  • Feed-Abos liegen zentral auf dem eigenen Server.
  • Gelesen/Ungelesen wird zwischen Geräten synchronisiert.
  • Markierte Artikel bleiben überall gleich.
  • Man kann den Client wechseln, ohne die komplette Feed-Sammlung neu aufzubauen.
  • Die Feeds lassen sich direkt im Browser lesen, wenn gerade kein Client vorhanden ist.


Updates der Feeds müssen zuverlässig laufen


Nextcloud News aktualisiert Feeds im Hintergrund. Damit das zuverlässig funktioniert, sollte eine produktive Nextcloud generell mit echten Cronjobs betrieben werden und nicht nur auf AJAX-Aufrufe im Browser angewiesen sein.

Wenn sehr viele Feeds hinzukommen, lohnt es sich außerdem, die Datenbank- und Cache-Konfiguration im Blick zu behalten. Dazu passt meine Anleitung Nextcloud mit Redis und APCu beschleunigen.

Mein Fazit


Meine Empfehlung ist heute weniger „nimm genau diesen einen Reader“ als früher. Ich würde Nextcloud News als zentrale Basis verwenden und anschließend pro Gerät den Client auswählen, der am besten passt. Genau dafür ist die offene API gedacht.

Aktuelle kompatible Programme findest du in der offiziellen Client-Liste von Nextcloud News.


Was bietet Nextcloud 2026? Mehr als nur eine private Cloud


Überarbeitet am 8. September 2026.

Als ich Nextcloud vor Jahren zum ersten Mal installiert habe, war mein Hauptgedanke ziemlich simpel: Ich wollte meine Dateien nicht bei Google Drive oder einem anderen großen Cloud-Anbieter ablegen. Inzwischen ist daraus deutlich mehr geworden. Nextcloud ist heute eher ein kompletter digitaler Arbeitsplatz, den man auf dem eigenen Server betreiben kann.

Das Schöne daran: Man muss nicht alle Funktionen benutzen. Wer nur Dateien synchronisieren möchte, kann genau das tun. Wer später Kalender, Kontakte, Videochat, Office oder einen RSS-Reader ergänzen möchte, installiert die passenden Apps dazu.

Table of Contents
Toggle

Dateien synchronisieren und teilen


Der Kern von Nextcloud ist weiterhin Nextcloud Files. Dateien können über den Browser, Desktop-Clients und die Apps für Smartphones erreicht und synchronisiert werden. Damit bekommt man im Alltag etwas Ähnliches wie Dropbox, OneDrive oder Google Drive – nur eben auf dem eigenen Server oder bei einem selbst gewählten Anbieter.

Dateien und Ordner lassen sich außerdem per Link teilen. Solche Freigaben können je nach Bedarf mit Passwort, Ablaufdatum und weiteren Einschränkungen versehen werden. Auch Freigaben zwischen Nextcloud-Servern sind möglich.

Kalender und Kontakte


Kalender und Kontakte gehören für mich zu den Funktionen, die eine eigene Cloud erst richtig nützlich machen. Nextcloud verwendet dafür offene Standards wie CalDAV und CardDAV. Dadurch lassen sich Kalender und Adressbücher mit vielen Programmen und Betriebssystemen synchronisieren.

Damit liegt nicht nur die Dateiablage auf dem eigenen Server, sondern auf Wunsch auch das persönliche Adressbuch und der Kalender.

Nextcloud Talk für Chat und Videotelefonie


Mit Nextcloud Talk gibt es Chats, Sprach- und Videoanrufe direkt innerhalb der eigenen Nextcloud. Das funktioniert im Browser und über mobile Apps. Gerade für kleine Teams, Familien oder Vereine ist das interessant, weil Dateien und Gespräche nicht auf mehrere Plattformen verteilt werden müssen.

Dokumente direkt im Browser bearbeiten


Auch Office gehört inzwischen fest zum Nextcloud-Ökosystem. Dokumente, Tabellen und Präsentationen können direkt im Browser bearbeitet und gemeinsam genutzt werden. Welche Office-Lösung zum Einsatz kommt, hängt von der eigenen Installation ab.

Für mich ist genau das einer der Punkte, an denen Nextcloud über eine reine Dateiablage hinausgeht: Eine Datei muss nicht erst heruntergeladen, lokal bearbeitet und anschließend wieder hochgeladen werden.

Fotos und Videos


Fotos vom Smartphone können automatisch zur Nextcloud hochgeladen werden. Für die Anzeige gibt es die integrierten Funktionen von Nextcloud sowie zusätzliche Apps aus dem App Store. Gerade bei großen Fotosammlungen lohnt es sich, unterschiedliche Lösungen auszuprobieren, weil die Anforderungen sehr verschieden sein können.

Notizen, Aufgaben, Projekte und RSS


Der Nextcloud App Store ist für mich einer der größten Vorteile. Dort findet man Erweiterungen für sehr unterschiedliche Einsatzzwecke. Beispiele sind:

  • Notes für einfache Notizen
  • Tasks für Aufgaben
  • Deck für Kanban-Boards und Projektplanung
  • News als RSS-Feedreader
  • Mail für E-Mail
  • Bookmarks für Lesezeichen
  • External Storage für zusätzliche Speicherziele

Man sollte trotzdem nicht jeden Fund aus dem App Store installieren. Weniger ist bei einer produktiven Nextcloud oft mehr. Ich schaue vorher, ob eine App aktiv gepflegt wird und zur verwendeten Nextcloud-Version passt.

Versionierung und Papierkorb


Nextcloud kann ältere Dateiversionen aufbewahren und gelöschte Dateien zunächst im Papierkorb behalten. Das ersetzt natürlich kein richtiges Backup, ist im Alltag aber enorm praktisch. Eine Datei versehentlich überschrieben oder gelöscht? Oft lässt sie sich mit wenigen Klicks zurückholen.

Nextcloud ist keine automatische Datensicherung


Das ist ein Punkt, den ich heute deutlicher schreiben würde als früher: Nur weil Dateien in Nextcloud liegen, sind sie noch nicht automatisch sicher. Wird der Server beschädigt, verschlüsselt oder versehentlich gelöscht, kann auch die Cloud weg sein.

Zu einer selbst gehosteten Nextcloud gehört deshalb ein externes Backup der Daten, der Datenbank und der Konfiguration. Wer die Cloud selbst betreibt, bekommt Kontrolle – übernimmt dafür aber eben auch Verantwortung.

Datenschutz und Kontrolle als größter Vorteil


Der für mich wichtigste Unterschied zu vielen klassischen Cloud-Diensten ist bis heute derselbe: Ich entscheide, wo die Daten liegen. Bei einem eigenen Server kenne ich den Speicherort, kann Backups selbst organisieren und bestimme, welche Erweiterungen installiert werden.

Natürlich bedeutet das auch Arbeit. Updates, Backups und Sicherheit gehören dazu. Wer damit gar nichts zu tun haben möchte, kann Nextcloud auch bei einem Anbieter mieten und muss den Server nicht selbst administrieren.

Für wen lohnt sich Nextcloud?


Nextcloud lohnt sich aus meiner Sicht besonders für Leute, die ihre Daten nicht auf mehrere Dienste verteilen möchten. Dateien bei Anbieter A, Kalender bei B, Kontakte bei C und Videotelefonie bei D – das kann Nextcloud zumindest teilweise unter einem Dach zusammenführen.

Man muss dafür kein Unternehmen sein. Auch für eine einzelne Person oder eine Familie kann eine kleine Nextcloud sinnvoll sein. Und wer Spaß am Selfhosting hat, findet im App-Ökosystem ziemlich schnell das nächste Projekt.

Wenn du Nextcloud selbst betreibst, solltest du dir auch meinen aktualisierten Beitrag Nextcloud richtig absichern ansehen.

Mehr Informationen gibt es direkt bei Nextcloud und im Nextcloud App Store.


This entry was edited (yesterday, 8:58 PM)

Was bietet Nextcloud 2026? Mehr als nur eine private Cloud


Nextcloud ist längst mehr als Datei-Sync: Files, Kalender, Kontakte, Talk, Office, Fotos, Aufgaben, RSS und viele Apps – ein Überblick für Einsteiger.

Überarbeitet am 8. September 2026.

Als ich Nextcloud vor Jahren zum ersten Mal installiert habe, war mein Hauptgedanke ziemlich simpel: Ich wollte meine Dateien nicht bei Google Drive oder einem anderen großen Cloud-Anbieter ablegen. Inzwischen ist daraus deutlich mehr geworden. Nextcloud ist heute eher ein kompletter digitaler Arbeitsplatz, den man auf dem eigenen Server betreiben kann.

Das Schöne daran: Man muss nicht alle Funktionen benutzen. Wer nur Dateien synchronisieren möchte, kann genau das tun. Wer später Kalender, Kontakte, Videochat, Office oder einen RSS-Reader ergänzen möchte, installiert die passenden Apps dazu.

Table of Contents
Toggle

Dateien synchronisieren und teilen


Der Kern von Nextcloud ist weiterhin Nextcloud Files. Dateien können über den Browser, Desktop-Clients und die Apps für Smartphones erreicht und synchronisiert werden. Damit bekommt man im Alltag etwas Ähnliches wie Dropbox, OneDrive oder Google Drive – nur eben auf dem eigenen Server oder bei einem selbst gewählten Anbieter.

Dateien und Ordner lassen sich außerdem per Link teilen. Solche Freigaben können je nach Bedarf mit Passwort, Ablaufdatum und weiteren Einschränkungen versehen werden. Auch Freigaben zwischen Nextcloud-Servern sind möglich.

Kalender und Kontakte


Kalender und Kontakte gehören für mich zu den Funktionen, die eine eigene Cloud erst richtig nützlich machen. Nextcloud verwendet dafür offene Standards wie CalDAV und CardDAV. Dadurch lassen sich Kalender und Adressbücher mit vielen Programmen und Betriebssystemen synchronisieren.

Damit liegt nicht nur die Dateiablage auf dem eigenen Server, sondern auf Wunsch auch das persönliche Adressbuch und der Kalender.

Nextcloud Talk für Chat und Videotelefonie


Mit Nextcloud Talk gibt es Chats, Sprach- und Videoanrufe direkt innerhalb der eigenen Nextcloud. Das funktioniert im Browser und über mobile Apps. Gerade für kleine Teams, Familien oder Vereine ist das interessant, weil Dateien und Gespräche nicht auf mehrere Plattformen verteilt werden müssen.

Dokumente direkt im Browser bearbeiten


Auch Office gehört inzwischen fest zum Nextcloud-Ökosystem. Dokumente, Tabellen und Präsentationen können direkt im Browser bearbeitet und gemeinsam genutzt werden. Welche Office-Lösung zum Einsatz kommt, hängt von der eigenen Installation ab.

Für mich ist genau das einer der Punkte, an denen Nextcloud über eine reine Dateiablage hinausgeht: Eine Datei muss nicht erst heruntergeladen, lokal bearbeitet und anschließend wieder hochgeladen werden.

Fotos und Videos


Fotos vom Smartphone können automatisch zur Nextcloud hochgeladen werden. Für die Anzeige gibt es die integrierten Funktionen von Nextcloud sowie zusätzliche Apps aus dem App Store. Gerade bei großen Fotosammlungen lohnt es sich, unterschiedliche Lösungen auszuprobieren, weil die Anforderungen sehr verschieden sein können.

Notizen, Aufgaben, Projekte und RSS


Der Nextcloud App Store ist für mich einer der größten Vorteile. Dort findet man Erweiterungen für sehr unterschiedliche Einsatzzwecke. Beispiele sind:

  • Notes für einfache Notizen
  • Tasks für Aufgaben
  • Deck für Kanban-Boards und Projektplanung
  • News als RSS-Feedreader
  • Mail für E-Mail
  • Bookmarks für Lesezeichen
  • External Storage für zusätzliche Speicherziele

Man sollte trotzdem nicht jeden Fund aus dem App Store installieren. Weniger ist bei einer produktiven Nextcloud oft mehr. Ich schaue vorher, ob eine App aktiv gepflegt wird und zur verwendeten Nextcloud-Version passt.

Versionierung und Papierkorb


Nextcloud kann ältere Dateiversionen aufbewahren und gelöschte Dateien zunächst im Papierkorb behalten. Das ersetzt natürlich kein richtiges Backup, ist im Alltag aber enorm praktisch. Eine Datei versehentlich überschrieben oder gelöscht? Oft lässt sie sich mit wenigen Klicks zurückholen.

Nextcloud ist keine automatische Datensicherung


Das ist ein Punkt, den ich heute deutlicher schreiben würde als früher: Nur weil Dateien in Nextcloud liegen, sind sie noch nicht automatisch sicher. Wird der Server beschädigt, verschlüsselt oder versehentlich gelöscht, kann auch die Cloud weg sein.

Zu einer selbst gehosteten Nextcloud gehört deshalb ein externes Backup der Daten, der Datenbank und der Konfiguration. Wer die Cloud selbst betreibt, bekommt Kontrolle – übernimmt dafür aber eben auch Verantwortung.

Datenschutz und Kontrolle als größter Vorteil


Der für mich wichtigste Unterschied zu vielen klassischen Cloud-Diensten ist bis heute derselbe: Ich entscheide, wo die Daten liegen. Bei einem eigenen Server kenne ich den Speicherort, kann Backups selbst organisieren und bestimme, welche Erweiterungen installiert werden.

Natürlich bedeutet das auch Arbeit. Updates, Backups und Sicherheit gehören dazu. Wer damit gar nichts zu tun haben möchte, kann Nextcloud auch bei einem Anbieter mieten und muss den Server nicht selbst administrieren.

Für wen lohnt sich Nextcloud?


Nextcloud lohnt sich aus meiner Sicht besonders für Leute, die ihre Daten nicht auf mehrere Dienste verteilen möchten. Dateien bei Anbieter A, Kalender bei B, Kontakte bei C und Videotelefonie bei D – das kann Nextcloud zumindest teilweise unter einem Dach zusammenführen.

Man muss dafür kein Unternehmen sein. Auch für eine einzelne Person oder eine Familie kann eine kleine Nextcloud sinnvoll sein. Und wer Spaß am Selfhosting hat, findet im App-Ökosystem ziemlich schnell das nächste Projekt.

Wenn du Nextcloud selbst betreibst, solltest du dir auch meinen aktualisierten Beitrag Nextcloud richtig absichern ansehen.

Mehr Informationen gibt es direkt bei Nextcloud und im Nextcloud App Store.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 7:53 PM)

Nextcloud Office mit Collabora einrichten: Docker, Reverse Proxy und Tests


Nextcloud Office mit Collabora Online einrichten: CODE per Docker, Reverse Proxy, HTTPS, WOPI-Allow-Liste und praktische Verbindungstests.

Überarbeitet am 8. September 2026.

Diese Anleitung ist einer der Artikel, bei denen das Alter besonders deutlich geworden ist. Meine ursprüngliche Version brauchte noch einen speziellen Ubuntu-16.04-Kernel und hantierte mit AUFS. Das ist heute Geschichte. Nextcloud Office basiert weiterhin auf Collabora Online beziehungsweise CODE, lässt sich aber inzwischen wesentlich entspannter einrichten.

Für kleine private Installationen gibt es sogar einen eingebauten CODE-Server. Wer etwas mehr Leistung möchte, betreibt Collabora separat – zum Beispiel als Docker-Container hinter einem Reverse Proxy. Genau diesen Weg zeige ich hier.

Falls Docker auf deinem Server noch fehlt, findest du hier meine aktualisierte Anleitung: Docker und Docker Compose unter Debian und Ubuntu installieren.

Table of Contents
Toggle

Was ist Nextcloud Office eigentlich?


Nextcloud Office ist die Office-Integration innerhalb von Nextcloud. Die eigentliche Bearbeitung übernimmt Collabora Online. Damit lassen sich unter anderem DOCX-, XLSX-, PPTX- und OpenDocument-Dateien direkt im Browser öffnen und gemeinsam bearbeiten.

Wenn du erstmal nur ausprobieren möchtest, ob dir das gefällt, reicht für eine kleine Installation oft der Built-in CODE Server. Er lässt sich als Nextcloud-App installieren und funktioniert in vielen Setups ohne zusätzlichen Container. Nextcloud weist allerdings selbst darauf hin, dass ein separater Collabora-Server für bessere Performance sinnvoller ist.

1. Eigene Subdomain für Collabora vorbereiten


Für einen separaten Collabora-Server würde ich eine eigene Subdomain verwenden, zum Beispiel:
office.example.deCode-Sprache: CSS (css)
Die Subdomain zeigt auf deinen Server und bekommt ein gültiges TLS-Zertifikat. Auch deine Nextcloud sollte natürlich über HTTPS erreichbar sein. Nextcloud und Collabora sollten dasselbe Protokoll verwenden – praktisch also beide HTTPS.

Mehr zu den grundlegenden Sicherheitsmaßnahmen findest du in Nextcloud richtig absichern.

2. Collabora CODE als Docker-Container starten


Das offizielle CODE-Image heißt weiterhin collabora/code. Zuerst laden wir es:
docker pull collabora/code
Danach starten wir Collabora nur auf localhost. So ist Port 9980 nicht direkt aus dem Internet erreichbar:
docker run -t -d \
-p 127.0.0.1:9980:9980 \
-e 'aliasgroup1=https://cloud.example.de:443' \
--restart always \
--cap-add MKNOD \
--name collabora \
collabora/codeCode-Sprache: JavaScript (javascript)
cloud.example.de ersetzt du durch die Domain deiner Nextcloud. Der Container lauscht anschließend nur auf 127.0.0.1:9980. Von außen kommt man später ausschließlich über den Reverse Proxy an Collabora heran.

3. Reverse Proxy vor Collabora setzen


Collabora benötigt einen Reverse Proxy, der die öffentliche Adresse https://office.example.de auf den lokalen Dienst an Port 9980 weiterleitet. Anders als in sehr alten Anleitungen heißen die wichtigen Pfade heute unter anderem:

  • /browser
  • /hosting/discovery
  • /hosting/capabilities
  • /cool
  • WebSocket-Verbindungen unter /cool/.../ws

Wer noch eine alte Konfiguration mit /lool und /loleaflet hat, sollte sie deshalb überprüfen. Die aktuellen Collabora-Komponenten verwenden coolwsd, /cool und /browser.

Da ich selbst Nginx nutze, würde ich dafür die aktuelle Reverse-Proxy-Vorlage von Collabora beziehungsweise Nextcloud als Ausgangspunkt nehmen. Besonders wichtig ist, dass die WebSocket-Verbindung mit durchgereicht wird. Eine reine normale HTTP-Weiterleitung reicht nicht.

4. Erst Collabora testen


Bevor ich Nextcloud konfiguriere, teste ich den Office-Server separat. Diese beiden Adressen sollten über den Browser erreichbar sein:
office.example.de/hosting/capa…
office.example.de/hosting/disc… JavaScript (javascript)
Auch direkt vom Nextcloud-Server aus kann man testen:
curl office.example.de/hosting/capa…
curl office.example.de/hosting/disc… JavaScript (javascript)
Wenn das schon nicht funktioniert, braucht man in Nextcloud noch gar nicht weiterzusuchen. Dann liegt das Problem eher bei DNS, Zertifikat, Firewall oder Reverse Proxy.

5. Nextcloud Office installieren und verbinden


In Nextcloud gehst du zu Apps → Office & Text und installierst beziehungsweise aktivierst Nextcloud Office.

Anschließend findest du unter Administrationseinstellungen → Office die Verbindung zum Collabora-Server. Dort trägst du ein:
office.example.deCode-Sprache: JavaScript (javascript)
Wenn alles stimmt, sollte Nextcloud die Verbindung erkennen. Danach kannst du direkt eine neue Textdatei oder Tabelle erstellen und testen.

6. WOPI-Zugriffe einschränken


Ein Punkt, den es in meiner alten Anleitung noch gar nicht gab: Nextcloud empfiehlt ausdrücklich, WOPI-Anfragen auf die erwarteten Collabora-Server zu begrenzen. Die entsprechende Allow-Liste findest du in den Office-Administrationseinstellungen.

Dort sollte möglichst nur die IP beziehungsweise das Netz eingetragen werden, aus dem dein Collabora-Server Nextcloud tatsächlich erreicht. Das verhindert, dass beliebige andere Systeme WOPI-Anfragen an deine Nextcloud stellen können.

7. Typische Fehler


Wenn Nextcloud Office nicht verbindet, prüfe ich in dieser Reihenfolge:

  • Kann der Browser Nextcloud und Collabora über HTTPS erreichen?
  • Kann Nextcloud office.example.de erreichen?
  • Kann Collabora wiederum die Nextcloud-Domain erreichen?
  • Ist das TLS-Zertifikat gültig?
  • Werden die /cool-WebSockets vom Reverse Proxy korrekt weitergeleitet?
  • Ist die WOPI-Allow-Liste korrekt?

Für den Container selbst helfen die Logs:
docker logs --tail 100 collabora
Die Nextcloud-Logs sollte man parallel ebenfalls ansehen. Sehr häufig ist es kein Office-Fehler, sondern schlicht eine nicht funktionierende Verbindung in eine der beiden Richtungen.

8. Collabora aktualisieren


Da CODE regelmäßig aktualisiert wird, sollte auch der Container nicht jahrelang unangetastet bleiben:
docker pull collabora/code
Anschließend wird der Container mit demselben Startbefehl neu erstellt. Wer stattdessen Docker Compose verwendet, kann das entsprechend mit docker compose pull und docker compose up -d erledigen.

Mein Fazit nach der Überarbeitung


Der Unterschied zu meiner ersten Collabora-Anleitung ist schon ziemlich absurd: Kein Xenial-Proposed, kein Kernel 4.4, kein AUFS-Gefrickel mehr. Für kleine Instanzen reicht heute sogar der eingebaute CODE-Server. Wer es etwas sauberer und performanter möchte, stellt einen separaten Collabora-Container hinter eine eigene HTTPS-Subdomain.

Wenn du noch am Anfang mit Nextcloud bist, findest du in Was bietet Nextcloud 2026? einen Überblick darüber, was die Cloud inzwischen alles kann.

Weiterführend: Nextcloud Office installieren, Collabora per Docker und Troubleshooting.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:30 PM)

Gesichtserkennung in Nextcloud: Face Recognition 2026 einrichten und testen


Face Recognition für Nextcloud 2026: aktueller Versionsstand, Voraussetzungen, face:setup, Hintergrundanalyse, Fortschritt und wichtige Hinweise zur Serverlast.

Überarbeitet am 8. September 2026.

Gesichter direkt auf dem eigenen Nextcloud-Server erkennen lassen – genau das fand ich an der Face-Recognition-App schon vor Jahren spannend. Meine alte Anleitung dazu war allerdings inzwischen kaum noch brauchbar: PHP 7.3, dlib und pdlib von Hand kompilieren, mehrere Gigabyte PHP-Memory-Limit und ein Hintergrundjob per disown.

Die App gibt es weiterhin und sie wird sogar noch entwickelt. Der Aufbau hat sich aber deutlich verändert. Deshalb geht es hier nicht mehr darum, irgendwelche uralten Build-Befehle zu kopieren, sondern darum, wie Face Recognition heute grundsätzlich eingerichtet und getestet wird.

Wenn du Nextcloud gerade grundsätzlich einrichtest, findest du in Was bietet Nextcloud 2026? einen aktuellen Überblick über die Möglichkeiten der Cloud.

Table of Contents
Toggle

Was macht die Face-Recognition-App?


Face Recognition analysiert Bilder innerhalb der Nextcloud, erkennt Gesichter und gruppiert ähnliche Gesichter zu Personen. Die Verarbeitung läuft auf dem eigenen Server. Die Fotos müssen dafür nicht zu Google, Apple oder einem anderen externen Dienst geschickt werden.

Die gefundenen Personen tauchen unter anderem in den persönlichen Einstellungen, in der Seitenleiste der Dateien-App und in der Fotos-App auf. Dort können Gesichter benannt und zusammengeführt werden.

Stand September 2026: auf die Version achten


Beim Schreiben dieser Aktualisierung gibt es eine Besonderheit: Das Upstream-Projekt dokumentiert mit Version 0.9.94 Unterstützung für Nextcloud 34 und mindestens PHP 8.2. Im offiziellen Nextcloud App Store wird aktuell dagegen noch eine ältere Veröffentlichung mit maximal Nextcloud 31 angezeigt.

Deshalb würde ich vor der Installation immer zuerst die aktuelle Projektversion und deren Anforderungen prüfen. Eine alte App-Version sollte nicht mit Gewalt in eine neuere Nextcloud installiert werden.

Voraussetzungen


Das aktuelle Projekt nennt für die neue Generation unter anderem diese Anforderungen:

  • eine unterstützte Nextcloud-Version,
  • Dlib-PHP-Bindings beziehungsweise PDlib,
  • PHP-Bzip2,
  • ausreichend Arbeitsspeicher.

Die Gesichtserkennung ist CPU- und speicherintensiv. Gerade bei zehntausenden Fotos würde ich die Analyse nicht während der Hauptnutzungszeit mit maximaler Parallelität starten.

Warum ich die alten dlib-Build-Befehle entfernt habe


In meiner früheren Anleitung wurde dlib aus GitHub kompiliert und pdlib mit Befehlen wie phpize7.3 gebaut. Das war schon damals empfindlich gegenüber PHP-Versionen und Distributionen.

Heute würde ich zuerst die Installationsdokumentation des Projekts für das eigene Betriebssystem verwenden und – wenn verfügbar – vorkompilierte Pakete bevorzugen. Wer eine abweichende PHP-Version oder ein ungewöhnliches Container-Image verwendet, muss PDlib unter Umständen weiterhin selbst bauen. Das ist aber kein sinnvoller Copy-and-Paste-Schritt für eine allgemeine Nextcloud-Anleitung.

1. App installieren und Voraussetzungen prüfen


Wenn die zu deiner Nextcloud passende App-Version verfügbar ist, installierst und aktivierst du Face Recognition. Danach würde ich zunächst prüfen, ob alle Abhängigkeiten erkannt werden, bevor irgendwelche echten Fotos analysiert werden.

Das Projekt stellt dafür inzwischen einen eigenen Setup-Befehl bereit:
sudo -E -u www-data php /var/www/nextcloud/occ face:setupCode-Sprache: JavaScript (javascript)
Damit werden die grundlegende Konfiguration und das benötigte Erkennungsmodell eingerichtet.

2. Erst mit einem Testbenutzer ausprobieren


Diesen Tipp finde ich aus der aktuellen Projektdokumentation besonders sinnvoll: Nicht sofort die komplette private Fotosammlung loslaufen lassen. Stattdessen zuerst einen Testbenutzer anlegen und ein paar unkritische Testbilder hochladen.

Dann kann die Analyse gezielt für diesen Benutzer gestartet werden:
sudo -E -u www-data php /var/www/nextcloud/occ face:background_job -u TESTBENUTZER -t 900Code-Sprache: JavaScript (javascript)
So sieht man relativ schnell, ob PDlib funktioniert, ob die Modelle geladen werden und ob das Ergebnis für die eigene Installation brauchbar ist.

3. Nutzer müssen die Analyse erlauben


Face Recognition analysiert nicht einfach ungefragt sämtliche Bilder aller Benutzer. In den persönlichen Einstellungen gibt es einen eigenen Bereich für die Gesichtserkennung. Dort kann der Nutzer die Analyse aktivieren und später gefundene Personen verwalten.

Das ist gerade bei einer Mehrbenutzer-Nextcloud wichtig: Gesichtserkennung ist nicht nur ein technisches Feature, sondern verarbeitet biometrisch interessante Informationen. Entsprechend bewusst sollte man die Funktion einsetzen.

4. Hintergrundanalyse sauber planen


Die App ist für einen regelmäßig laufenden Hintergrundjob ausgelegt. Der zentrale Befehl ist heute:
sudo -E -u www-data php /var/www/nextcloud/occ face:background_jobCode-Sprache: JavaScript (javascript)
Auf einem Server mit mehreren CPU-Kernen kann parallel gearbeitet werden:
sudo -E -u www-data php /var/www/nextcloud/occ face:background_job --workers=4Code-Sprache: JavaScript (javascript)
Mehr Worker bedeuten aber auch mehr Speicherverbrauch, weil jeder Worker sein eigenes Modell lädt. Ich würde deshalb klein anfangen und die Last beobachten, statt direkt alle Kerne freizugeben.

5. Fortschritt anzeigen


Statt wie früher anhand irgendwelcher Prozesslisten zu rätseln, gibt es inzwischen einen eigenen Fortschrittsbefehl:
sudo -E -u www-data php /var/www/nextcloud/occ face:progressCode-Sprache: JavaScript (javascript)
Für eine Zusammenfassung von Bildern, Gesichtern und Personen gibt es außerdem:
sudo -E -u www-data php /var/www/nextcloud/occ face:statsCode-Sprache: JavaScript (javascript)

Alben nach Personen synchronisieren


Die App kann erkannte Personen auch mit der Nextcloud-Fotos-App verknüpfen. Dafür existiert inzwischen:
sudo -E -u www-data php /var/www/nextcloud/occ face:sync-albumsCode-Sprache: JavaScript (javascript)
Das ist deutlich näher an dem, was man von modernen Fotoverwaltungen kennt, als die sehr frühe Version der App, über die ich ursprünglich geschrieben hatte.

Serverlast nicht unterschätzen


Gesichtserkennung kann eine Menge Rechenzeit fressen. Besonders der erste Durchlauf über eine große Bildersammlung ist kein Job, den ich ungeplant zur Mittagszeit starten würde. Sinnvoller ist ein Zeitfenster, in dem der Server wenig genutzt wird.

Auch das restliche Nextcloud-Setup sollte sauber laufen. Für das normale Memory Caching habe ich meinen Artikel Nextcloud mit Redis und APCu beschleunigen aktualisiert.

Datenschutz nicht vergessen


Der große Charme dieser Lösung ist für mich weiterhin, dass die Bilder auf der eigenen Nextcloud bleiben. Trotzdem sollte man Gesichtserkennung nicht einfach als gewöhnliches Thumbnail-Plugin betrachten. Wer eine Nextcloud für mehrere Menschen betreibt, sollte transparent machen, dass und wie Gesichtsdaten analysiert werden.

Die allgemeine Absicherung des Servers habe ich hier zusammengefasst: Nextcloud richtig absichern.

Weiterführend: Face Recognition auf GitHub und Face Recognition im Nextcloud App Store.


Nextcloud mit Redis und APCu beschleunigen: Caching richtig einrichten


Überarbeitet am 8. September 2026.

Redis gehört bei vielen Nextcloud-Installationen inzwischen fast zur Grundausstattung. Früher hatte ich Redis vor allem eingebaut, weil die Galerie und andere Bereiche gefühlt schneller reagieren sollten. Heute würde ich das genauer formulieren: Für den lokalen Cache ist APCu normalerweise die bessere Wahl, Redis spielt seine Stärke vor allem beim verteilten Cache und beim Transactional File Locking aus.

Gerade das File Locking ist wichtig. Ohne Redis kann Nextcloud dafür die Datenbank verwenden, was unnötig Last erzeugt. Bei einer größeren oder stärker genutzten Instanz lohnt sich Redis deshalb sehr schnell.

Wenn du Nextcloud gerade erst aufsetzt, findest du in meinem Beitrag Was bietet Nextcloud 2026? einen Überblick. Für die Absicherung des Servers habe ich außerdem Nextcloud richtig absichern aktualisiert.

Table of Contents
Toggle

Was macht APCu und was macht Redis?


APCu ist ein sehr schneller lokaler Cache innerhalb von PHP. Nextcloud empfiehlt ihn für memcache.local. Redis eignet sich dagegen besonders für memcache.distributed und memcache.locking.

Auf einem typischen einzelnen Linux-Server sieht eine sinnvolle Kombination deshalb so aus:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',Code-Sprache: PHP (php)
Für einen sehr kleinen privaten Server reicht laut Nextcloud auch nur APCu. Wer Redis aber ohnehin installiert hat oder die Datenbank beim File Locking entlasten möchte, kann Redis zusätzlich verwenden.

1. Redis und APCu unter Debian oder Ubuntu installieren

sudo apt update
sudo apt install redis-server php-redis php-apcu
Danach prüfe ich zuerst, ob Redis läuft:
systemctl status redis-server
Die PHP-Module kannst du ebenfalls kontrollieren:
php -m | grep -Ei 'redis|apcu'Code-Sprache: JavaScript (javascript)
Je nach Setup muss anschließend PHP-FPM oder der Webserver neu gestartet werden, damit die neu installierten PHP-Module geladen werden.

2. Redis lokal besser per Unix-Socket anbinden


Läuft Redis auf demselben Server wie Nextcloud, empfiehlt die aktuelle Nextcloud-Dokumentation einen Unix-Socket. Dadurch muss Redis nicht über TCP angesprochen werden.

In /etc/redis/redis.conf sollten die Socket-Einstellungen vorhanden beziehungsweise aktiviert sein:
unixsocket /run/redis/redis-server.sock
unixsocketperm 770
Damit der Webserver auf den Socket zugreifen darf, wird der typische Debian-Webserver-Nutzer www-data zur Redis-Gruppe hinzugefügt:
sudo usermod -a -G redis www-data
sudo systemctl restart redis-server
Danach muss auch der PHP-/Webserver-Prozess neu gestartet werden, damit die neue Gruppenmitgliedschaft greift.

3. Nextcloud config.php anpassen


Die Datei liegt bei einer klassischen Installation meistens unter:
/var/www/nextcloud/config/config.phpCode-Sprache: JavaScript (javascript)
Innerhalb des bestehenden Konfigurationsarrays ergänze ich:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',

'redis' => [
'host' => '/run/redis/redis-server.sock',
'port' => 0,
],Code-Sprache: PHP (php)
Wichtig: Nicht einfach einen zweiten 'redis' => [...]-Block anlegen, wenn bereits einer existiert. Dann muss der vorhandene Eintrag angepasst werden.

Alternative: Redis über 127.0.0.1


Wenn du keinen Unix-Socket nutzen möchtest, kann Redis lokal auch über TCP angesprochen werden:
'redis' => [
'host' => '127.0.0.1',
'port' => 6379,
],Code-Sprache: PHP (php)
Redis sollte dabei nicht ungeschützt am öffentlichen Netzwerk lauschen. Für eine reine lokale Nextcloud gibt es normalerweise keinen Grund, Port 6379 ins Internet freizugeben.

Brauche ich noch requirepass?


In meiner alten Anleitung hatte ich für Redis zwingend ein Passwort über requirepass eingerichtet. Das ist bei einer ausschließlich lokalen Verbindung über einen korrekt berechtigten Unix-Socket nicht zwingend erforderlich. Wer Redis über TCP oder zwischen mehreren Servern betreibt, sollte die Redis-Authentifizierung und Netzwerkkonfiguration dagegen bewusst absichern.

Ein festes Beispielpasswort gehört ohnehin nicht in eine Anleitung – und erst recht nicht in eine produktive config.php.

4. Konfiguration testen


Zuerst prüfe ich Redis selbst:
redis-cli ping
Bei einer TCP-Konfiguration sollte als Antwort PONG erscheinen. Beim Unix-Socket kannst du direkt den Socket angeben:
redis-cli -s /run/redis/redis-server.sock ping
Danach kontrolliere ich Nextcloud:
sudo -E -u www-data php /var/www/nextcloud/occ statusCode-Sprache: JavaScript (javascript)
Zusätzlich lohnt sich ein Blick unter Administrationseinstellungen → Übersicht. Ist kein lokaler Cache konfiguriert oder stimmt etwas mit der Einrichtung nicht, meldet Nextcloud das dort normalerweise ziemlich deutlich.

APCu nicht zu klein dimensionieren


Ein Punkt, der bei größeren Instanzen schnell auffällt: Der Standardwert für den APCu-Speicher kann zu klein sein. Nextcloud nennt 128 MB als sinnvollen Startwert, wenn der Standard nicht reicht. Die Einstellung erfolgt in der passenden PHP-Konfiguration zum Beispiel über:
apc.shm_size=128M
Ob mehr nötig ist, hängt von Anzahl der Benutzer, Apps und PHP-Worker ab. Einfach blind auf mehrere Gigabyte hochdrehen würde ich nicht.

Was Redis nicht automatisch schneller macht


Redis ist kein Wunderknopf für eine langsame Nextcloud. Wenn PHP-FPM falsch dimensioniert ist, die Datenbank hängt, die Platte langsam ist oder Vorschaubilder den Server beschäftigen, wird Redis diese Probleme nicht plötzlich verschwinden lassen.

Seine größten Vorteile liegen in sauberem Caching und vor allem darin, die Datenbank beim Transactional File Locking zu entlasten. Zusammen mit APCu ergibt das für viele selbst gehostete Installationen eine sehr sinnvolle Kombination.

Wenn du deine Nextcloud generell überarbeitest, lohnt sich auch mein Artikel zum sicheren Verschieben des Nextcloud-Datenverzeichnisses per Bind Mount.

Weiterführend: Nextcloud-Dokumentation zu Memory Caching und Transactional File Locking.


This entry was edited (yesterday, 8:34 PM)

Bestehende Nextcloud in Docker umziehen: Datenbank, Daten und Konfiguration übernehmen


Eine bestehende Nextcloud sicher in Docker migrieren: Datenbank, config.php, Daten und Custom Apps übernehmen, Versionen passend halten und anschließend prüfen.

Überarbeitet am 8. September 2026.

Meine Nextcloud von einer klassischen Serverinstallation in Docker umzuziehen war damals eines meiner größeren Projekte. Die alte Anleitung funktioniert heute aber nur noch teilweise: Docker Compose wurde noch als einzelne Binärdatei installiert, Containernamen waren fest eincodiert und nebenbei wurde sogar eine längst veraltete Collabora-Konfiguration mit umgezogen.

Heute würde ich den Umzug deutlich sauberer machen: erst sichern, dann auf exakt derselben Nextcloud-Hauptversion in Docker wiederherstellen und erst danach über Updates nachdenken.

Wenn Docker auf dem Zielserver noch nicht eingerichtet ist, findest du hier meine aktuelle Anleitung: Docker und Docker Compose unter Debian und Ubuntu installieren.

Table of Contents
Toggle

Was muss bei einer Nextcloud wirklich mit?


Für eine vollständige Migration reicht es nicht, nur den Nextcloud-Datenordner zu kopieren. Zu einer bestehenden Installation gehören mindestens:

  • die Datenbank,
  • das Nextcloud-Datenverzeichnis,
  • config/config.php und die übrige relevante Konfiguration,
  • eigene beziehungsweise zusätzliche Apps,
  • eigene Themes, falls vorhanden.

Gerade Kalender, Kontakte, Freigaben, App-Einstellungen und viele Metadaten liegen in der Datenbank. Ein reines Kopieren der Dateien wäre deshalb keine vollständige Migration.

1. Quell- und Zielversion müssen zusammenpassen


Das ist einer der wichtigsten Punkte. Wenn auf dem alten Server beispielsweise Nextcloud Hauptversion X läuft, würde ich auf dem Docker-Ziel zunächst ebenfalls ein Image dieser Hauptversion verwenden.

Ich würde einen Serverumzug nicht gleichzeitig als Sprung über mehrere Nextcloud-Hauptversionen benutzen. Das offizielle Docker-Image unterstützt Upgrades nur jeweils um eine Hauptversion. Erst die Migration sauber abschließen, anschließend kontrolliert aktualisieren.

2. Vollständiges Backup erstellen


Bevor irgendetwas verändert wird, kommt ein vollständiges Backup. Ich schalte Nextcloud dafür zuerst in den Wartungsmodus:
sudo -E -u www-data php /var/www/nextcloud/occ maintenance:mode --onCode-Sprache: JavaScript (javascript)
Danach sichere ich Datenbank, Konfiguration und Datenverzeichnis. Bei MariaDB/MySQL kann ein Dump beispielsweise so erstellt werden:
mysqldump --single-transaction --routines --triggers \
-u nextcloud -p nextcloud > nextcloud.sqlCode-Sprache: CSS (css)
Zusätzlich sichere ich mindestens:
/var/www/nextcloud/config/
/DEIN/NEXTCLOUD-DATENVERZEICHNIS/
/var/www/nextcloud/custom_apps/
/var/www/nextcloud/themes/Code-Sprache: JavaScript (javascript)
Wo dein Datenverzeichnis tatsächlich liegt, siehst du in der config.php beim Eintrag datadirectory. Falls du Daten auf eine andere Platte verschieben möchtest, habe ich dafür inzwischen eine separate Anleitung: Nextcloud-Datenverzeichnis sicher per Bind Mount verschieben.

3. Docker-Umgebung aufbauen


Auf dem Zielsystem definiere ich die komplette Infrastruktur in einer compose.yaml. Für eine typische Installation sind das mindestens Nextcloud und eine Datenbank; Redis würde ich ebenfalls direkt mit einplanen.

Ein stark vereinfachtes Grundgerüst kann so aussehen:
services:
db:
image: mariadb:11.8
restart: unless-stopped
env_file:
- db.env
volumes:
- ./db:/var/lib/mysql

redis:
image: redis:alpine
restart: unless-stopped

app:
image: nextcloud:DEINE_HAUPTVERSION-apache
restart: unless-stopped
depends_on:
- db
- redis
ports:
- "127.0.0.1:8080:80"
volumes:
- ./nextcloud:/var/www/htmlCode-Sprache: JavaScript (javascript)
DEINE_HAUPTVERSION ersetzt du bewusst durch die Version, die zu deiner bestehenden Installation passt. Für produktive Setups würde ich außerdem Passwörter und Secrets nicht direkt in die Compose-Datei schreiben.

Die genaue Struktur kann natürlich anders aussehen – etwa mit externem Datenverzeichnis, separaten Volumes oder FPM statt Apache. Entscheidend ist, dass die persistenten Daten nicht nur im flüchtigen Container liegen.

4. Basis einmal erstellen


Das offizielle Nextcloud-Docker-Projekt empfiehlt bei der Migration, die neue Infrastruktur zunächst einmal mit Compose aufzubauen. Dadurch entstehen die benötigten Volumes und die Datenbankumgebung:
docker compose up -d
Anschließend stoppe ich die App wieder beziehungsweise verhindere, dass parallel schon Benutzer mit der leeren Installation arbeiten, während die alten Daten eingespielt werden.

5. Datenbank wiederherstellen


Die vorhandene Nextcloud-Datenbank muss jetzt in den neuen Datenbankcontainer. Das offizielle Docker-Projekt zeigt dafür einen robusten Weg: Dump in den Container kopieren und dort importieren.
docker compose cp ./nextcloud.sql db:/nextcloud.sql
Der eigentliche Import hängt von Benutzername, Datenbankname und Datenbanktyp ab. Bei MariaDB/MySQL wird der Dump anschließend mit dem Datenbank-Client in die vorbereitete Nextcloud-Datenbank eingelesen. Passwörter würde ich dabei nicht als Beispielwert in die Shell-History schreiben, sondern aus der eigenen sicheren Konfiguration verwenden.

6. config.php übernehmen und Docker-Pfade anpassen


Jetzt kommt die bestehende config.php in die Docker-Installation. Besonders der Datenbankhost ändert sich häufig. Wenn der Compose-Dienst db heißt, sieht der Eintrag beispielsweise so aus:
'dbhost' => 'db:3306',Code-Sprache: PHP (php)
Außerdem prüfe ich trusted_domains, Reverse-Proxy-Einstellungen, Redis und datadirectory. Die Pfade müssen aus Sicht des Containers stimmen – nicht aus Sicht des Hosts.

7. Daten und Custom Apps übernehmen


Die Nutzerdaten werden jetzt in das vorgesehene persistente Volume beziehungsweise den eingebundenen Host-Pfad kopiert. Dateirechte und Zeitstempel sollten erhalten bleiben.

Eigene Apps kopiere ich nur dann mit, wenn ich sie wirklich noch brauche. Normale Apps aus dem Nextcloud App Store lassen sich oft sauber neu installieren. Alte, seit Jahren ungepflegte Apps möchte ich nicht automatisch in die neue Umgebung mitschleppen.

8. Nextcloud starten und mit OCC prüfen

docker compose up -d
Danach kontrolliere ich zuerst die Container:
docker compose ps
docker compose logs --tail 100 app
OCC wird im Container ausgeführt:
docker compose exec -u www-data app php occ status
Wenn alles stimmt, kann der Wartungsmodus in der neuen Installation beendet werden:
docker compose exec -u www-data app php occ maintenance:mode --offCode-Sprache: CSS (css)

9. Cron richtig einrichten


Meine alte Anleitung hatte für einzelne Apps mehrere selbstgebastelte Cronjobs. Das würde ich heute nicht mehr als Standard empfehlen. Nextcloud selbst braucht einen regelmäßig ausgeführten cron.php-Job.

Je nach Docker-Aufbau kann dafür ein separater Cron-Container oder ein Host-Cronjob verwendet werden. Entscheidend ist, dass in Nextcloud unter den Grundeinstellungen Cron als Hintergrundjob ausgewählt ist und der Job zuverlässig läuft.

10. Reverse Proxy erst danach sauber anbinden


Ich lasse Nextcloud im Beispiel nur auf 127.0.0.1:8080 lauschen und setze davor meinen normalen Nginx-Reverse-Proxy mit HTTPS. So muss der Container nicht selbst öffentlich Port 80 oder 443 übernehmen.

Bei einem Reverse Proxy müssen insbesondere Host, Protokoll und echte Client-IP korrekt an Nextcloud weitergereicht werden. Mehr dazu steht auch in meiner aktualisierten Anleitung Nextcloud richtig absichern.

Collabora nicht mehr in diese Migration quetschen


Früher hatte ich in diesem Artikel gleich noch eine Collabora-Nginx-Konfiguration angehängt. Das machte die Anleitung unnötig unübersichtlich und die verwendeten /lool-Pfade sind längst veraltet. Nextcloud Office gehört deshalb in eine eigene Anleitung: Nextcloud Office mit Collabora einrichten.

Erst wenn alles läuft: alte Installation abschalten


Ich würde das alte System nicht sofort löschen. Erst anmelden, Dateien öffnen, Upload testen, Kalender und Kontakte prüfen, Hintergrundjobs kontrollieren und einen neuen Backup-Lauf durchführen.

Wenn die Docker-Installation einige Zeit sauber gelaufen ist und ein Restore-fähiges Backup existiert, kann die alte Installation endgültig außer Betrieb gehen.

Weiterführend: offizielles Nextcloud-Docker-Image und Docker-Dokumentation inklusive Migration bestehender Installationen.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:35 PM)

Nextcloud Full Text Search einrichten: Dateien durchsuchen mit Elasticsearch oder SQL


Nextcloud Full Text Search 2026: aktuelle Apps, Elasticsearch oder SQL als Plattform, sichere Anbindung und wichtige OCC-Befehle für Test und Indexierung.

Überarbeitet am 8. September 2026.

Meine alte Anleitung für die Nextcloud-Volltextsuche war inzwischen ein ziemliches Museum: Java 8, Elasticsearch 7.12, ReadonlyREST, ein separat installiertes ingest-attachment-Plugin und Hinweise auf PHP 7.4. Die gute Nachricht ist: Full Text Search gibt es weiterhin und wird aktiv gepflegt. Der Aufbau ist aber heute deutlich klarer.

Das Wichtigste zuerst: Nextcloud Full Text Search besteht nicht aus nur einer App. Es ist ein kleines Baukastensystem aus einer Kern-App, einem Inhalts-Provider und einer Suchplattform.

Wenn du erstmal wissen möchtest, was Nextcloud sonst noch kann, findest du hier meinen aktuellen Überblick: Was bietet Nextcloud 2026?.

Table of Contents
Toggle

Die drei Bausteine der Volltextsuche


Für die Suche in Dateien brauchst du normalerweise diese Komponenten:

  • Full text search – die Kern-App und das Such-Framework
  • Full text search – Files – liest Inhalte und Metadaten aus Dateien
  • eine Platform-App – dort wird der Suchindex gespeichert

Als Plattform gibt es unter anderem Full text search – Elasticsearch Platform. Inzwischen existiert außerdem eine SQL Platform, die den Index in der Nextcloud-Datenbank speichert und ohne separaten Elasticsearch-Server auskommt.

Welche Plattform würde ich nehmen?


Für eine kleine Installation würde ich mir zuerst die SQL Platform ansehen. Sie spart einen zusätzlichen Dienst und damit auch RAM, Updates und Wartung.

Bei vielen Dateien, mehreren Benutzern oder einer größeren Installation bleibt Elasticsearch interessant. Dafür läuft ein zusätzlicher Suchserver, der speziell für solche Indizes gebaut ist.

Wichtig: Die aktuelle Nextcloud-App Full text search – Elasticsearch Platform ist seit Version 26 nur noch mit Elasticsearch 8 kompatibel. Meine alten Elasticsearch-7-Beispiele gehören deshalb nicht mehr in eine heutige Anleitung.

1. Die Nextcloud-Apps installieren


Im Nextcloud App Store installierst du für die Elasticsearch-Variante:

  • Full text search
  • Full text search – Files
  • Full text search – Elasticsearch Platform

Alternativ kannst du als Plattform Full text search – SQL Platform verwenden.

Wer lieber mit OCC arbeitet, kann die App-IDs auch darüber aktivieren. Die eigentliche Konfiguration erledige ich anschließend aber gern in der Administrationsoberfläche, weil dort sofort sichtbar ist, welcher Provider und welche Plattform ausgewählt sind.

2. Elasticsearch nur intern erreichbar machen


Wenn du Elasticsearch nutzt, braucht Nextcloud Zugriff auf dessen HTTP-Schnittstelle. Port 9200 sollte aber nicht einfach offen im Internet hängen.

Auf einem einzelnen Docker-Host binde ich solche Dienste lieber nur an localhost oder lasse Nextcloud und Elasticsearch direkt über ein internes Docker-Netz miteinander sprechen.
127.0.0.1:9200:9200Code-Sprache: CSS (css)
Damit ist Elasticsearch vom Host erreichbar, aber nicht automatisch aus dem Internet. Wie Docker und Docker Compose aktuell installiert werden, habe ich hier beschrieben: Docker und Docker Compose installieren.

Ich pinne in dieser Anleitung bewusst keine konkrete Elasticsearch-Patchversion fest. Vor der Installation würde ich immer die Kompatibilitätsangabe der aktuellen Nextcloud-Elasticsearch-App prüfen. Alte Blogposts mit Elasticsearch 6 oder 7 sollte man nicht einfach nachbauen.

3. Full Text Search in Nextcloud konfigurieren


Unter den Administrationseinstellungen der Volltextsuche wählst du den Datei-Provider und deine Suchplattform aus.

Bei einem lokal auf dem Host laufenden Elasticsearch könnte die Adresse beispielsweise so aussehen:
127.0.0.1:9200Code-Sprache: JavaScript (javascript)
Laufen Nextcloud und Elasticsearch beide in Docker, ist stattdessen meist der interne Servicename sinnvoll, zum Beispiel:
http://elasticsearch:9200Code-Sprache: JavaScript (javascript)
Zusätzlich wird ein Indexname festgelegt, zum Beispiel nextcloud. Zugangsdaten oder TLS hängen davon ab, wie du deinen Elasticsearch-Server abgesichert hast.

4. Erst testen, dann indexieren


Einer der praktischsten Befehle ist inzwischen der eingebaute Test:
sudo -E -u www-data php /var/www/nextcloud/occ fulltextsearch:testCode-Sprache: JavaScript (javascript)
Der Test prüft unter anderem, ob Provider und Suchplattform geladen werden können, ob sich Dokumente indexieren lassen und ob Suchanfragen Ergebnisse zurückgeben.

Erst wenn dieser Test sauber durchläuft, starte ich den eigentlichen Index:
sudo -E -u www-data php /var/www/nextcloud/occ fulltextsearch:indexCode-Sprache: JavaScript (javascript)
Bei vielen Dateien kann der erste Lauf ziemlich lange dauern. Dann gehört der Prozess in eine stabile SSH-Sitzung wie tmux oder screen – nicht in ein Terminal, das man versehentlich nach zehn Minuten schließt.

5. Konfiguration kontrollieren


Für eine schnelle Übersicht gibt es:
sudo -E -u www-data php /var/www/nextcloud/occ fulltextsearch:checkCode-Sprache: JavaScript (javascript)
Damit sieht man, welche Plattform ausgewählt ist und welche Provider aktiv sind. Bei Fehlern ist das oft hilfreicher als direkt den ganzen Index zu löschen und neu aufzubauen.

6. Laufende Indexierung


Für fortlaufende Indexierung gibt es außerdem:
sudo -E -u www-data php /var/www/nextcloud/occ fulltextsearch:liveCode-Sprache: JavaScript (javascript)
Das ist ein dauerhaft laufender Prozess und gehört deshalb nicht einfach in eine normale SSH-Sitzung. Je nach Installation kann man ihn beispielsweise über systemd oder einen Prozessmanager betreiben. Wer nur gelegentlich indexiert, kann auch bewusst mit normalen Indexläufen arbeiten.

Was ist mit OCR?


Hier war meine alte Anleitung zu pauschal. Volltextsuche und OCR sind nicht dasselbe. Die Full-Text-Search-Apps können Inhalte unterstützter Dateien indexieren, aber aus jedem beliebigen Foto oder Scan wird nicht automatisch zuverlässig durchsuchbarer Text.

Wenn dein Hauptziel gescannte Dokumente sind, würde ich zuerst prüfen, ob die Dateien bereits eine OCR-Textebene besitzen – beispielsweise weil sie aus Paperless-ngx oder einer Scanner-Software kommen. Dann kann die Volltextsuche diesen Text wesentlich einfacher indexieren.

Und Nextant mit Solr?


Nextant war der Vorgänger, über den ich hier früher viel geschrieben habe. Die App ist aber nur bis Nextcloud 13 freigegeben und seit Jahren nicht mehr gepflegt. Meine alten Solr-/Nextant-Installationsanleitungen sind deshalb keine sinnvolle Empfehlung mehr.

Für eine aktuelle Nextcloud würde ich heute beim aktiv gepflegten Full-Text-Search-Framework bleiben und eine aktuelle Platform-App auswählen.

Auch Caching und Serverleistung im Blick behalten


Volltextindexierung erzeugt ordentlich Last auf CPU, RAM und Datenträger. Wenn die Nextcloud ohnehin schon langsam ist, sollte man nicht nur am Suchdienst drehen. Für das normale Nextcloud-Caching habe ich deshalb auch Redis und APCu für Nextcloud aktualisiert.

Weiterführend: Full text search, Full text search – Files, Elasticsearch Platform und SQL Platform.


Nextcloud mit Redis und APCu beschleunigen: Caching richtig einrichten


Überarbeitet am 8. September 2026.

Redis gehört bei vielen Nextcloud-Installationen inzwischen fast zur Grundausstattung. Früher hatte ich Redis vor allem eingebaut, weil die Galerie und andere Bereiche gefühlt schneller reagieren sollten. Heute würde ich das genauer formulieren: Für den lokalen Cache ist APCu normalerweise die bessere Wahl, Redis spielt seine Stärke vor allem beim verteilten Cache und beim Transactional File Locking aus.

Gerade das File Locking ist wichtig. Ohne Redis kann Nextcloud dafür die Datenbank verwenden, was unnötig Last erzeugt. Bei einer größeren oder stärker genutzten Instanz lohnt sich Redis deshalb sehr schnell.

Wenn du Nextcloud gerade erst aufsetzt, findest du in meinem Beitrag Was bietet Nextcloud 2026? einen Überblick. Für die Absicherung des Servers habe ich außerdem Nextcloud richtig absichern aktualisiert.

Table of Contents
Toggle

Was macht APCu und was macht Redis?


APCu ist ein sehr schneller lokaler Cache innerhalb von PHP. Nextcloud empfiehlt ihn für memcache.local. Redis eignet sich dagegen besonders für memcache.distributed und memcache.locking.

Auf einem typischen einzelnen Linux-Server sieht eine sinnvolle Kombination deshalb so aus:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',Code-Sprache: PHP (php)
Für einen sehr kleinen privaten Server reicht laut Nextcloud auch nur APCu. Wer Redis aber ohnehin installiert hat oder die Datenbank beim File Locking entlasten möchte, kann Redis zusätzlich verwenden.

1. Redis und APCu unter Debian oder Ubuntu installieren

sudo apt update
sudo apt install redis-server php-redis php-apcu
Danach prüfe ich zuerst, ob Redis läuft:
systemctl status redis-server
Die PHP-Module kannst du ebenfalls kontrollieren:
php -m | grep -Ei 'redis|apcu'Code-Sprache: JavaScript (javascript)
Je nach Setup muss anschließend PHP-FPM oder der Webserver neu gestartet werden, damit die neu installierten PHP-Module geladen werden.

2. Redis lokal besser per Unix-Socket anbinden


Läuft Redis auf demselben Server wie Nextcloud, empfiehlt die aktuelle Nextcloud-Dokumentation einen Unix-Socket. Dadurch muss Redis nicht über TCP angesprochen werden.

In /etc/redis/redis.conf sollten die Socket-Einstellungen vorhanden beziehungsweise aktiviert sein:
unixsocket /run/redis/redis-server.sock
unixsocketperm 770
Damit der Webserver auf den Socket zugreifen darf, wird der typische Debian-Webserver-Nutzer www-data zur Redis-Gruppe hinzugefügt:
sudo usermod -a -G redis www-data
sudo systemctl restart redis-server
Danach muss auch der PHP-/Webserver-Prozess neu gestartet werden, damit die neue Gruppenmitgliedschaft greift.

3. Nextcloud config.php anpassen


Die Datei liegt bei einer klassischen Installation meistens unter:
/var/www/nextcloud/config/config.phpCode-Sprache: JavaScript (javascript)
Innerhalb des bestehenden Konfigurationsarrays ergänze ich:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',

'redis' => [
'host' => '/run/redis/redis-server.sock',
'port' => 0,
],Code-Sprache: PHP (php)
Wichtig: Nicht einfach einen zweiten 'redis' => [...]-Block anlegen, wenn bereits einer existiert. Dann muss der vorhandene Eintrag angepasst werden.

Alternative: Redis über 127.0.0.1


Wenn du keinen Unix-Socket nutzen möchtest, kann Redis lokal auch über TCP angesprochen werden:
'redis' => [
'host' => '127.0.0.1',
'port' => 6379,
],Code-Sprache: PHP (php)
Redis sollte dabei nicht ungeschützt am öffentlichen Netzwerk lauschen. Für eine reine lokale Nextcloud gibt es normalerweise keinen Grund, Port 6379 ins Internet freizugeben.

Brauche ich noch requirepass?


In meiner alten Anleitung hatte ich für Redis zwingend ein Passwort über requirepass eingerichtet. Das ist bei einer ausschließlich lokalen Verbindung über einen korrekt berechtigten Unix-Socket nicht zwingend erforderlich. Wer Redis über TCP oder zwischen mehreren Servern betreibt, sollte die Redis-Authentifizierung und Netzwerkkonfiguration dagegen bewusst absichern.

Ein festes Beispielpasswort gehört ohnehin nicht in eine Anleitung – und erst recht nicht in eine produktive config.php.

4. Konfiguration testen


Zuerst prüfe ich Redis selbst:
redis-cli ping
Bei einer TCP-Konfiguration sollte als Antwort PONG erscheinen. Beim Unix-Socket kannst du direkt den Socket angeben:
redis-cli -s /run/redis/redis-server.sock ping
Danach kontrolliere ich Nextcloud:
sudo -E -u www-data php /var/www/nextcloud/occ statusCode-Sprache: JavaScript (javascript)
Zusätzlich lohnt sich ein Blick unter Administrationseinstellungen → Übersicht. Ist kein lokaler Cache konfiguriert oder stimmt etwas mit der Einrichtung nicht, meldet Nextcloud das dort normalerweise ziemlich deutlich.

APCu nicht zu klein dimensionieren


Ein Punkt, der bei größeren Instanzen schnell auffällt: Der Standardwert für den APCu-Speicher kann zu klein sein. Nextcloud nennt 128 MB als sinnvollen Startwert, wenn der Standard nicht reicht. Die Einstellung erfolgt in der passenden PHP-Konfiguration zum Beispiel über:
apc.shm_size=128M
Ob mehr nötig ist, hängt von Anzahl der Benutzer, Apps und PHP-Worker ab. Einfach blind auf mehrere Gigabyte hochdrehen würde ich nicht.

Was Redis nicht automatisch schneller macht


Redis ist kein Wunderknopf für eine langsame Nextcloud. Wenn PHP-FPM falsch dimensioniert ist, die Datenbank hängt, die Platte langsam ist oder Vorschaubilder den Server beschäftigen, wird Redis diese Probleme nicht plötzlich verschwinden lassen.

Seine größten Vorteile liegen in sauberem Caching und vor allem darin, die Datenbank beim Transactional File Locking zu entlasten. Zusammen mit APCu ergibt das für viele selbst gehostete Installationen eine sehr sinnvolle Kombination.

Wenn du deine Nextcloud generell überarbeitest, lohnt sich auch mein Artikel zum sicheren Verschieben des Nextcloud-Datenverzeichnisses per Bind Mount.

Weiterführend: Nextcloud-Dokumentation zu Memory Caching und Transactional File Locking.


This entry was edited (yesterday, 8:32 PM)

Nextcloud mit LDAP/OpenLDAP verbinden: Benutzer und Gruppen einbinden


Nextcloud mit einem vorhandenen LDAP- oder OpenLDAP-Server verbinden: PHP-LDAP, user_ldap, LDAPS, Benutzer- und Gruppenfilter sowie OCC-Diagnose.

Überarbeitet am 8. September 2026.

Nextcloud kann Benutzer und Gruppen direkt aus einem LDAP-Verzeichnis oder Microsoft Active Directory übernehmen. Das ist praktisch, wenn mehrere Dienste dieselben Benutzerkonten verwenden sollen und man nicht für jede Anwendung eigene Accounts pflegen möchte.

Meine alte Anleitung ging noch einen Schritt weiter und beschrieb gleichzeitig den Aufbau eines OpenLDAP-Servers inklusive phpLDAPadmin. Das war inzwischen zu viel auf einmal und enthielt ein paar Dinge, die ich heute aus Sicherheitsgründen nicht mehr so empfehlen würde. Diese Anleitung konzentriert sich deshalb auf das, was sie eigentlich leisten soll: einen vorhandenen LDAP-Server sauber mit Nextcloud verbinden.

Wer seine Nextcloud generell absichern möchte, findet die wichtigsten Punkte in Nextcloud richtig absichern.

Table of Contents
Toggle

Was Nextcloud mit LDAP macht


Das LDAP User and Group Backend liest Benutzer und Gruppen aus dem Verzeichnis ein. Die Nutzer melden sich anschließend mit ihren LDAP-Zugangsdaten an Nextcloud an. Separate Nextcloud-Benutzerkonten müssen dafür nicht angelegt werden.

Nextcloud verwendet das LDAP-Verzeichnis dabei grundsätzlich lesend für Benutzer- und Gruppeninformationen. Quoten, Freigaben und andere Nextcloud-spezifische Einstellungen werden weiterhin in Nextcloud verwaltet.

1. PHP-LDAP installieren


Für die LDAP-Anbindung benötigt PHP das LDAP-Modul. Unter Debian und Ubuntu lässt sich das normalerweise so installieren:
sudo apt update
sudo apt install php-ldap
Danach muss der verwendete PHP-FPM- beziehungsweise Webserver-Dienst neu gestartet werden, damit das Modul geladen wird.

Prüfen kannst du das zum Beispiel mit:
php -m | grep -i ldap

2. LDAP User and Group Backend aktivieren


Die benötigte Nextcloud-App heißt LDAP user and group backend und hat die App-ID user_ldap. Sie kann in der App-Verwaltung aktiviert werden.

Alternativ geht es über OCC:
sudo -E -u www-data php /var/www/nextcloud/occ app:enable user_ldapCode-Sprache: JavaScript (javascript)
Danach erscheint in den Administrationseinstellungen die LDAP-Konfiguration.

3. Verbindung zum LDAP-Server eintragen


Im ersten Reiter wird die eigentliche Serververbindung eingerichtet. Benötigt werden mindestens Host, Port und Base-DN.

Ein typisches Beispiel könnte so aussehen:
Host: ldaps://ldap.example.de
Port: 636
Base DN: dc=example,dc=deCode-Sprache: JavaScript (javascript)
Läuft LDAP auf demselben Server und ausschließlich lokal, kann das Setup natürlich anders aussehen. Bei einer Verbindung über das Netzwerk würde ich die LDAP-Anmeldedaten aber nicht unverschlüsselt quer durchs Netz schicken.

Nextcloud kann für die Suche einen eigenen LDAP-Systembenutzer verwenden. Genau das ist sinnvoller als ein vollwertiges Administratorkonto. Dieser Bind-Benutzer benötigt nur die Rechte, die Nextcloud zum Lesen der benötigten Benutzer- und Gruppeninformationen braucht.
uid=nextcloudsystemuser,ou=service,dc=example,dc=de

Port 389 nicht einfach ins Internet öffnen


In meiner alten Anleitung stand pauschal:
sudo ufw allow 389
Das würde ich heute so nicht mehr empfehlen. Wenn Nextcloud und LDAP auf demselben Server laufen, muss dafür überhaupt kein öffentlicher Port geöffnet werden. Laufen sie auf unterschiedlichen Servern, sollte die Firewall nur die tatsächlich beteiligten Systeme miteinander kommunizieren lassen.

Bei LDAPS wird üblicherweise Port 636 verwendet. Entscheidend ist nicht die Portnummer allein, sondern dass die Verbindung verschlüsselt ist, Zertifikate geprüft werden und der Dienst nicht unnötig für das gesamte Internet erreichbar ist.

4. Benutzerfilter festlegen


Im Reiter Benutzer legst du fest, welche LDAP-Konten überhaupt in Nextcloud erscheinen sollen. Nextcloud erkennt viele typische Objektklassen automatisch.

Bei einem klassischen OpenLDAP ist inetOrgPerson häufig ein passender Ausgangspunkt. Noch besser ist es, nur eine bestimmte Gruppe für Nextcloud freizugeben.
(&(objectClass=inetOrgPerson)(memberOf=cn=nextcloudusers,ou=groups,dc=example,dc=de))
Ob ein solcher memberOf-Filter funktioniert, hängt von der Konfiguration des LDAP-Servers ab. Deshalb würde ich zuerst die grafische Auswahl in Nextcloud verwenden und nur bei Bedarf mit eigenen LDAP-Filtern arbeiten.

5. Login-Attribute auswählen


Im Reiter für die Login-Attribute stellst du ein, womit sich Benutzer anmelden dürfen. Häufig ist das der LDAP-Benutzername, je nach Verzeichnis zum Beispiel uid oder bei Active Directory sAMAccountName.

Optional kann auch die E-Mail-Adresse als Login erlaubt werden. Ich würde nur die Attribute freischalten, die tatsächlich gebraucht werden.

6. Gruppen auswählen


Im Gruppen-Reiter wird festgelegt, welche LDAP-Gruppen in Nextcloud sichtbar sein sollen. Typische Objektklassen sind beispielsweise group oder posixGroup.

Auch hier gilt: lieber gezielt die benötigten Gruppen auswählen, statt das komplette Verzeichnis unnötig nach Nextcloud zu spiegeln.

7. LDAP-Konfiguration mit OCC prüfen


Nextcloud bringt inzwischen sehr brauchbare LDAP-Kommandos mit. Zuerst kannst du dir die vorhandene Konfiguration anzeigen lassen:
sudo -E -u www-data php /var/www/nextcloud/occ ldap:show-configCode-Sprache: JavaScript (javascript)
Nach einem Benutzer suchen:
sudo -E -u www-data php /var/www/nextcloud/occ ldap:search BENUTZERNAMECode-Sprache: JavaScript (javascript)
Und einen konkreten LDAP-Benutzer prüfen:
sudo -E -u www-data php /var/www/nextcloud/occ ldap:check-user BENUTZERNAMECode-Sprache: JavaScript (javascript)
Das ist deutlich angenehmer, als bei jedem Fehler nur in der Weboberfläche herumzuklicken.

Zertifikatsprüfung nicht abschalten


Wenn LDAPS oder TLS wegen eines Zertifikatsfehlers nicht funktioniert, sollte die Ursache behoben werden. Nextcloud bietet zwar eine Möglichkeit, die Zertifikatsprüfung für Tests abzuschalten, die Dokumentation kennzeichnet das aber ausdrücklich als Testoption.

Sauberer ist es, die CA beziehungsweise das Serverzertifikat auf dem Nextcloud-Server korrekt bekannt zu machen.

LDAP und Caching


LDAP-Abfragen werden von Nextcloud gecacht. Gerade bei vielen Benutzern und Gruppen hilft deshalb eine vernünftige Memory-Cache-Konfiguration. Dazu passt meine aktualisierte Anleitung Nextcloud mit Redis und APCu beschleunigen.

Mein Fazit


LDAP mit Nextcloud zu verbinden ist heute deutlich komfortabler als bei meinem ersten Versuch vor vielen Jahren. Nextcloud erkennt viele Attribute selbst, bietet Filter für Benutzer und Gruppen und bringt inzwischen umfangreiche OCC-Kommandos zur Diagnose mit.

Der wichtigste Unterschied zu meiner alten Anleitung: Ich würde LDAP nicht mehr nebenbei mit einem frei erreichbaren phpLDAPadmin-Webpanel und pauschal geöffnetem Port aufbauen. Erst ein sauber abgesichertes LDAP-Verzeichnis, dann Nextcloud als Client anbinden.

Weiterführend: Nextcloud-Dokumentation zur LDAP-Authentifizierung und LDAP-Kommandos mit OCC.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:27 PM)

ocDownloader für Nextcloud nicht mehr nutzen: aktuelle Alternativen


ocDownloader wird nicht mehr gepflegt. Warum die alte Nextcloud-App heute keine gute Wahl mehr ist und welche aktuellen Alternativen ich stattdessen nutze.

Überarbeitet am 8. September 2026.

Wichtig vorweg: ocDownloader wird nicht mehr gepflegt und sollte auf einer aktuellen Nextcloud nicht mehr neu eingerichtet werden.

Diese Seite bleibt bewusst als Hinweis bestehen, weil ältere Anleitungen und Suchtreffer noch darauf verweisen können. Die eigentliche Installationsanleitung habe ich aus dem veröffentlichten Bestand genommen.

Table of Contents
Toggle

Warum ocDownloader heute keine gute Wahl mehr ist


  • keine verlässlichen Sicherheitsupdates,
  • Probleme mit aktuellen Nextcloud-Versionen möglich,
  • alte Abhängigkeiten wie youtube-dl und historische aria2-Setups,
  • keine gute Basis für eine öffentlich erreichbare Nextcloud.

Gerade bei einer App, die Downloads aus dem Internet direkt auf den eigenen Server holt, möchte ich keine ungepflegte Altsoftware einsetzen.

Meine heutige Alternative: MediaFetch


Inzwischen habe ich selbst an einer moderneren Lösung gearbeitet. MediaFetch ist mein eigener Ansatz für Downloads direkt innerhalb von Nextcloud.

Wer sich für die Entwicklung und den Hintergrund interessiert, findet dort auch den aktuellen Stand des Projekts.

Auch Net Loader ist aus diesem Thema entstanden


Ein weiterer Ansatz ist Net Loader. Das Projekt ist aus der Idee entstanden, die alten Downloader-Konzepte für eine heutige Nextcloud neu zu denken, statt immer weiter an längst überholten Installationsanleitungen festzuhalten.

Alte ocDownloader-Anleitungen besser nicht mehr nachbauen


Im Netz finden sich noch Anleitungen mit offenen aria2-RPC-Ports, deaktivierter Zertifikatsprüfung oder sehr alten Abhängigkeiten. Solche Setups würde ich heute nicht mehr übernehmen.

Wenn deine Nextcloud öffentlich erreichbar ist, solltest du außerdem die grundlegende Absicherung prüfen. Dazu habe ich den Artikel Nextcloud richtig absichern komplett aktualisiert.

Kurz gesagt: ocDownloader darf in meinem Blog als historischer Hinweis bleiben – für eine neue Installation würde ich aber eine aktuell gepflegte Lösung verwenden.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:26 PM)

Nextcloud mit 2FA absichern: TOTP, Backup-Codes und App-Passwörter


Nextcloud mit Zwei-Faktor-Authentifizierung absichern: TOTP einrichten, Backup-Codes sichern, App-Passwörter verwenden und 2FA bei Bedarf erzwingen.

Überarbeitet am 8. September 2026.

Die Zwei-Faktor-Authentifizierung gehört für mich bei einer öffentlich erreichbaren Nextcloud inzwischen zu den wichtigsten Schutzmaßnahmen. Ein Passwort allein kann gestohlen, wiederverwendet oder durch Phishing abgegriffen werden. Mit einem zweiten Faktor reicht das Passwort allein nicht mehr aus.

In meiner alten Version dieses Artikels ging es noch um WinAuth auf dem PC. Das ist heute nicht mehr der Punkt. Nextcloud unterstützt verschiedene 2FA-Verfahren und bringt mehrere Provider bereits mit. Für viele private Installationen ist TOTP weiterhin der einfachste Einstieg.

Wenn du deine Nextcloud insgesamt absichern möchtest, findest du die wichtigsten Punkte gesammelt in Nextcloud richtig absichern.

Table of Contents
Toggle

Welche 2FA-Verfahren unterstützt Nextcloud?


Nextcloud ist bei der Zwei-Faktor-Authentifizierung modular aufgebaut. Zu den typischen Möglichkeiten gehören:

  • TOTP-Codes aus einer Authenticator-App,
  • Bestätigung über bereits angemeldete Nextcloud-Geräte,
  • Hardware- beziehungsweise FIDO-basierte Faktoren über passende Provider,
  • Backup-Codes für den Notfall.

Der Administrator muss mindestens einen passenden 2FA-Provider aktivieren. Danach kann der Benutzer den zweiten Faktor in seinen persönlichen Sicherheitseinstellungen einrichten. 2FA kann vom Administrator auch für alle Nutzer oder nur bestimmte Gruppen verpflichtend gemacht werden.

1. TOTP-Provider aktivieren


Für TOTP benötigt Nextcloud den Two-Factor TOTP Provider. Er ist bei aktuellen Nextcloud-Versionen vorhanden, kann aber deaktiviert sein. Als Administrator findest du ihn unter den Apps bei den deaktivierten Apps beziehungsweise im Bereich Sicherheit.

Alternativ lässt sich der Provider über OCC installieren:
sudo -E -u www-data php /var/www/nextcloud/occ app:install twofactor_totpCode-Sprache: JavaScript (javascript)
Ist die App bereits installiert, aber deaktiviert, genügt:
sudo -E -u www-data php /var/www/nextcloud/occ app:enable twofactor_totpCode-Sprache: JavaScript (javascript)

2. TOTP im Benutzerkonto einrichten


Im eigenen Nextcloud-Konto öffnest du die persönlichen Einstellungen und gehst in den Bereich Sicherheit. Dort lässt sich TOTP aktivieren.

Nextcloud zeigt anschließend einen QR-Code beziehungsweise ein geheimes TOTP-Secret an. Diesen QR-Code scannst du mit einer kompatiblen Authenticator-App. Nextcloud verwendet den üblichen TOTP-Standard, sodass du nicht an eine bestimmte App gebunden bist.

Danach gibst du den aktuell erzeugten Code einmal zur Bestätigung in Nextcloud ein. Ab dem nächsten Login werden Passwort und TOTP-Code verlangt.

Die Uhrzeit muss stimmen


TOTP-Codes sind zeitabhängig. Wenn die Uhr auf dem Nextcloud-Server oder dem Gerät deutlich falsch läuft, können eigentlich richtige Codes abgelehnt werden. Deshalb sollte die Systemzeit auf dem Server sauber per NTP synchronisiert werden.

3. Unbedingt Backup-Codes erzeugen


Das ist der Teil, den man gern auf später verschiebt und dann genau im falschen Moment vermisst. Nextcloud kann einmalig verwendbare Backup-Codes erzeugen. Diese sind für den Fall gedacht, dass das Smartphone verloren geht, kaputt ist oder der normale zweite Faktor nicht mehr funktioniert.

Die Backup-Codes gehören an einen sicheren Ort, aber nicht auf dasselbe Smartphone, auf dem auch der Authenticator liegt. Ein Passwortmanager oder eine sicher verwahrte Offline-Kopie ist sinnvoller.

4. App-Passwörter für Joplin, DAV und andere Clients


Sobald 2FA aktiviert ist, können viele klassische Clients nicht mehr einfach mit Benutzername und normalem Nextcloud-Passwort auf das Konto zugreifen. Dafür gibt es gerätespezifische App-Passwörter.

Ein eigenes App-Passwort ist zum Beispiel sinnvoll für:

  • WebDAV-Programme,
  • CalDAV- und CardDAV-Clients,
  • ältere Synchronisationsprogramme,
  • Joplin mit Nextcloud-Synchronisation.

Der Vorteil: Du musst dein eigentliches Kontopasswort nicht an jede Anwendung weitergeben. Außerdem kann einem einzelnen Gerät der Zugriff später wieder entzogen werden.

Ein praktisches Beispiel findest du in meiner aktualisierten Anleitung Joplin mit Nextcloud synchronisieren.

5. 2FA als Administrator erzwingen


Wer mehrere Benutzer verwaltet, kann 2FA auch verpflichtend machen. Das geht unter Administrationseinstellungen → Sicherheit. Nextcloud kann die Pflicht systemweit oder nur für ausgewählte Gruppen setzen.

Per OCC lässt sich der aktuelle Zustand ebenfalls prüfen:
sudo -E -u www-data php /var/www/nextcloud/occ twofactorauth:state BENUTZERNAMECode-Sprache: JavaScript (javascript)
Für alle Nutzer lässt sich die Pflicht beispielsweise so aktivieren:
sudo -E -u www-data php /var/www/nextcloud/occ twofactorauth:enforce --onCode-Sprache: JavaScript (javascript)
Bevor ich so etwas für alle erzwinge, würde ich allerdings testen, ob die benötigten Clients und Wiederherstellungswege funktionieren.

Was tun, wenn der zweite Faktor verloren geht?


Als Benutzer sind die Backup-Codes die beste Rückfallebene. Hat man keine mehr, kann ein Administrator bei unterstützten Providern die 2FA-Methode eines Benutzers über OCC deaktivieren.
sudo -E -u www-data php /var/www/nextcloud/occ twofactorauth:disable BENUTZERNAME PROVIDER_IDCode-Sprache: JavaScript (javascript)
Das sollte natürlich nur nach einer sauberen Identitätsprüfung passieren. Sonst würde aus der Wiederherstellungsfunktion selbst eine Sicherheitslücke.

2FA ist wenig Aufwand für deutlich mehr Schutz


Im Alltag ist der zusätzliche Schritt beim Login schnell Gewohnheit. Dafür bringt 2FA einen echten Sicherheitsgewinn: Ein gestohlenes Passwort reicht nicht mehr aus, um sich direkt an der Nextcloud anzumelden.

Für mein eigenes Setup würde ich mindestens für Administratorkonten TOTP oder einen vergleichbaren zweiten Faktor aktivieren, Backup-Codes sicher ablegen und für externe Programme konsequent App-Passwörter verwenden.

Weiterführend: Nextcloud Benutzerhandbuch zu 2FA und Nextcloud Admin-Dokumentation zu 2FA.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:24 PM)

Joplin mit Nextcloud synchronisieren: aktuelle WebDAV-Anleitung


Joplin mit der eigenen Nextcloud synchronisieren: richtige WebDAV-Adresse, App-Passwort bei 2FA, typische Fehler und wichtige Hinweise zum Sync-Ordner.

Überarbeitet am 8. September 2026.

Joplin nutze ich bis heute gern für Notizen, weil die App nicht an einen bestimmten Cloud-Anbieter gebunden ist. Besonders praktisch: Die Synchronisation funktioniert weiterhin direkt mit Nextcloud. Damit bleiben Notizen, Anhänge und Aufgaben auf dem eigenen Server, während Joplin die eigentliche Notizverwaltung übernimmt.

Wer Nextcloud noch nicht kennt, findet in meinem Artikel Was bietet Nextcloud 2026? einen aktuellen Überblick. Und wenn deine Nextcloud öffentlich erreichbar ist, lohnt sich zusätzlich der Beitrag Nextcloud richtig absichern.

Table of Contents
Toggle

Was wird eigentlich synchronisiert?


Joplin ist eine lokale Notiz-App mit eigener Synchronisation. Die Notizen liegen also zunächst auf dem jeweiligen Gerät. Über Nextcloud werden anschließend Notizen, Notizbücher, Tags und Ressourcen wie Bilder oder Dateianhänge zwischen den Geräten abgeglichen.

Das ist ein wichtiger Unterschied zur normalen Nextcloud-Notes-App: Joplin verwaltet seine Daten selbst. Der Ordner auf der Nextcloud ist deshalb nicht dafür gedacht, die dortigen Dateien direkt von Hand zu bearbeiten.

1. Einen eigenen Joplin-Ordner in Nextcloud anlegen


Ich lege in Nextcloud zuerst einen eigenen Ordner an, zum Beispiel:
Joplin
Der Ordner sollte ausschließlich von Joplin für die Synchronisation verwendet werden. Die offizielle Joplin-Dokumentation empfiehlt ausdrücklich, diesen Sync-Ordner nicht zusätzlich mit dem Nextcloud-Desktop-Client zu synchronisieren. Sonst arbeiten zwei Synchronisationsmechanismen auf denselben Daten.

2. Die richtige WebDAV-Adresse herausfinden


In Nextcloud findest du die WebDAV-Adresse in der Dateien-App unter den Einstellungen. Je nach Installation kann sie zum Beispiel so aussehen:
cloud.example.de/remote.php/da… JavaScript (javascript)
Joplin unterstützt weiterhin auch die ältere Form:
cloud.example.de/remote.php/we… JavaScript (javascript)
Am einfachsten ist es, die von deiner eigenen Nextcloud angezeigte WebDAV-Adresse zu kopieren und den Ordner Joplin anzuhängen.

3. Nextcloud in Joplin als Synchronisationsziel auswählen


In Joplin öffnest du die Einstellungen und wählst als Synchronisationsziel Nextcloud. Danach werden WebDAV-Adresse, Benutzername und Passwort eingetragen.

Wenn alles stimmt, sollte die Verbindung getestet werden können. Anschließend startet die Synchronisation automatisch beziehungsweise lässt sich manuell anstoßen.

Wichtig bei aktivierter Zwei-Faktor-Authentifizierung


Wenn du für dein Nextcloud-Konto 2FA aktiviert hast, solltest du für Joplin ein eigenes App-Passwort verwenden. Das normale Kontopasswort gehört dann nicht in Joplin.

App-Passwörter kannst du in Nextcloud in den persönlichen Sicherheitseinstellungen erzeugen. So lässt sich der Zugriff für Joplin später auch gezielt wieder entziehen, ohne dein normales Passwort ändern zu müssen.

Typische Fehler bei der Einrichtung


Wenn Joplin nicht synchronisiert, sind es erstaunlich oft dieselben Ursachen:

  • die WebDAV-Adresse ist nicht vollständig,
  • der Ordner Joplin wurde vorher nicht angelegt,
  • Benutzername oder Passwort sind falsch,
  • bei aktivierter 2FA wird statt eines App-Passworts das normale Passwort verwendet,
  • ein Reverse Proxy oder eine Webserver-Regel blockiert WebDAV-Anfragen.

Joplin führt eigene Logs. Wenn die Synchronisation scheitert, lohnt sich deshalb zuerst ein Blick in das Protokoll der App. Dort steht meist deutlich mehr als nur „Synchronisation fehlgeschlagen“.

Nicht im Nextcloud-Ordner herumeditieren


Ein Punkt aus meiner alten Version des Artikels war missverständlich: Die Dateien im Joplin-Sync-Ordner sehen zwar teilweise nach Textdateien aus, bilden aber zusammen mit weiteren Metadaten den Synchronisationsbestand von Joplin. Dieser Ordner ist kein normales Markdown-Archiv zum manuellen Bearbeiten.

Wenn du einzelne Notizen außerhalb von Joplin brauchst, solltest du die Exportfunktionen von Joplin verwenden, statt im Synchronisationsordner Dateien zu verändern.

Joplin und Nextcloud passen weiterhin gut zusammen


Für mich ist die Kombination weiterhin interessant: Joplin kümmert sich um Notizen, Aufgaben, Anhänge und die lokale Arbeit auf den Geräten; Nextcloud stellt lediglich den selbst gehosteten Synchronisationsspeicher bereit.

Damit muss ich weder Dropbox noch OneDrive nur für meine Notizen verwenden. Gleichzeitig bleibt Joplin flexibel: Sollte ich das Synchronisationsziel irgendwann wechseln wollen, bin ich nicht dauerhaft an Nextcloud gebunden.

Weiterführend: Joplin-Dokumentation zur Nextcloud-Synchronisation und Übersicht der Joplin-Synchronisationsziele.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:22 PM)

Nextcloud mit Redis und APCu beschleunigen: Caching richtig einrichten


Nextcloud-Caching richtig einrichten: APCu für lokalen Cache, Redis für verteilten Cache und File Locking – inklusive Unix-Socket, Tests und aktueller config.php.

Überarbeitet am 8. September 2026.

Redis gehört bei vielen Nextcloud-Installationen inzwischen fast zur Grundausstattung. Früher hatte ich Redis vor allem eingebaut, weil die Galerie und andere Bereiche gefühlt schneller reagieren sollten. Heute würde ich das genauer formulieren: Für den lokalen Cache ist APCu normalerweise die bessere Wahl, Redis spielt seine Stärke vor allem beim verteilten Cache und beim Transactional File Locking aus.

Gerade das File Locking ist wichtig. Ohne Redis kann Nextcloud dafür die Datenbank verwenden, was unnötig Last erzeugt. Bei einer größeren oder stärker genutzten Instanz lohnt sich Redis deshalb sehr schnell.

Wenn du Nextcloud gerade erst aufsetzt, findest du in meinem Beitrag Was bietet Nextcloud 2026? einen Überblick. Für die Absicherung des Servers habe ich außerdem Nextcloud richtig absichern aktualisiert.

Table of Contents
Toggle

Was macht APCu und was macht Redis?


APCu ist ein sehr schneller lokaler Cache innerhalb von PHP. Nextcloud empfiehlt ihn für memcache.local. Redis eignet sich dagegen besonders für memcache.distributed und memcache.locking.

Auf einem typischen einzelnen Linux-Server sieht eine sinnvolle Kombination deshalb so aus:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',Code-Sprache: PHP (php)
Für einen sehr kleinen privaten Server reicht laut Nextcloud auch nur APCu. Wer Redis aber ohnehin installiert hat oder die Datenbank beim File Locking entlasten möchte, kann Redis zusätzlich verwenden.

1. Redis und APCu unter Debian oder Ubuntu installieren

sudo apt update
sudo apt install redis-server php-redis php-apcu
Danach prüfe ich zuerst, ob Redis läuft:
systemctl status redis-server
Die PHP-Module kannst du ebenfalls kontrollieren:
php -m | grep -Ei 'redis|apcu'Code-Sprache: JavaScript (javascript)
Je nach Setup muss anschließend PHP-FPM oder der Webserver neu gestartet werden, damit die neu installierten PHP-Module geladen werden.

2. Redis lokal besser per Unix-Socket anbinden


Läuft Redis auf demselben Server wie Nextcloud, empfiehlt die aktuelle Nextcloud-Dokumentation einen Unix-Socket. Dadurch muss Redis nicht über TCP angesprochen werden.

In /etc/redis/redis.conf sollten die Socket-Einstellungen vorhanden beziehungsweise aktiviert sein:
unixsocket /run/redis/redis-server.sock
unixsocketperm 770
Damit der Webserver auf den Socket zugreifen darf, wird der typische Debian-Webserver-Nutzer www-data zur Redis-Gruppe hinzugefügt:
sudo usermod -a -G redis www-data
sudo systemctl restart redis-server
Danach muss auch der PHP-/Webserver-Prozess neu gestartet werden, damit die neue Gruppenmitgliedschaft greift.

3. Nextcloud config.php anpassen


Die Datei liegt bei einer klassischen Installation meistens unter:
/var/www/nextcloud/config/config.phpCode-Sprache: JavaScript (javascript)
Innerhalb des bestehenden Konfigurationsarrays ergänze ich:
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',

'redis' => [
'host' => '/run/redis/redis-server.sock',
'port' => 0,
],Code-Sprache: PHP (php)
Wichtig: Nicht einfach einen zweiten 'redis' => [...]-Block anlegen, wenn bereits einer existiert. Dann muss der vorhandene Eintrag angepasst werden.

Alternative: Redis über 127.0.0.1


Wenn du keinen Unix-Socket nutzen möchtest, kann Redis lokal auch über TCP angesprochen werden:
'redis' => [
'host' => '127.0.0.1',
'port' => 6379,
],Code-Sprache: PHP (php)
Redis sollte dabei nicht ungeschützt am öffentlichen Netzwerk lauschen. Für eine reine lokale Nextcloud gibt es normalerweise keinen Grund, Port 6379 ins Internet freizugeben.

Brauche ich noch requirepass?


In meiner alten Anleitung hatte ich für Redis zwingend ein Passwort über requirepass eingerichtet. Das ist bei einer ausschließlich lokalen Verbindung über einen korrekt berechtigten Unix-Socket nicht zwingend erforderlich. Wer Redis über TCP oder zwischen mehreren Servern betreibt, sollte die Redis-Authentifizierung und Netzwerkkonfiguration dagegen bewusst absichern.

Ein festes Beispielpasswort gehört ohnehin nicht in eine Anleitung – und erst recht nicht in eine produktive config.php.

4. Konfiguration testen


Zuerst prüfe ich Redis selbst:
redis-cli ping
Bei einer TCP-Konfiguration sollte als Antwort PONG erscheinen. Beim Unix-Socket kannst du direkt den Socket angeben:
redis-cli -s /run/redis/redis-server.sock ping
Danach kontrolliere ich Nextcloud:
sudo -E -u www-data php /var/www/nextcloud/occ statusCode-Sprache: JavaScript (javascript)
Zusätzlich lohnt sich ein Blick unter Administrationseinstellungen → Übersicht. Ist kein lokaler Cache konfiguriert oder stimmt etwas mit der Einrichtung nicht, meldet Nextcloud das dort normalerweise ziemlich deutlich.

APCu nicht zu klein dimensionieren


Ein Punkt, der bei größeren Instanzen schnell auffällt: Der Standardwert für den APCu-Speicher kann zu klein sein. Nextcloud nennt 128 MB als sinnvollen Startwert, wenn der Standard nicht reicht. Die Einstellung erfolgt in der passenden PHP-Konfiguration zum Beispiel über:
apc.shm_size=128M
Ob mehr nötig ist, hängt von Anzahl der Benutzer, Apps und PHP-Worker ab. Einfach blind auf mehrere Gigabyte hochdrehen würde ich nicht.

Was Redis nicht automatisch schneller macht


Redis ist kein Wunderknopf für eine langsame Nextcloud. Wenn PHP-FPM falsch dimensioniert ist, die Datenbank hängt, die Platte langsam ist oder Vorschaubilder den Server beschäftigen, wird Redis diese Probleme nicht plötzlich verschwinden lassen.

Seine größten Vorteile liegen in sauberem Caching und vor allem darin, die Datenbank beim Transactional File Locking zu entlasten. Zusammen mit APCu ergibt das für viele selbst gehostete Installationen eine sehr sinnvolle Kombination.

Wenn du deine Nextcloud generell überarbeitest, lohnt sich auch mein Artikel zum sicheren Verschieben des Nextcloud-Datenverzeichnisses per Bind Mount.

Weiterführend: Nextcloud-Dokumentation zu Memory Caching und Transactional File Locking.


Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.


This entry was edited (yesterday, 8:21 PM)
in reply to nothingcorporate

It's a new pre-configured hyprland/arch distro, that raised $15 million dollars somehow. The founder of Omarchy is DHH, the creator of Ruby-on-rails.

The distro is probably AI/vibe-coding, setup to give LLM agents easy access to the system. Some of the previously mentioned $15 million is actually in the form of donated AI credits to code the distro with.

The distro has some controversial decisions like bundling Spotify and Zoom into the install, when Linux (and especially arch) is known for low bloat and user choice.

Some of the money they've raised is going to Vaxry the dev of Hyprland. There are various opinions on this, a lot of people like hyprland but Vaxry is kinda insane polish dude obsessed with anime porn.

Overall I think most people care because it's a lot of money raised for a distro, especially when people disagree with the developmental decisions and goals. People would rather see that money go to other places, and are questioning why so many companies were willing to sponsor Omarchy specifically.

Omarchy’s Kitty Config Exposed Users to Remote Code Execution


Omarchy has changed its Kitty configuration after a security issue was identified with allow_remote_control yes.

That setting allows Kitty’s remote-control protocol to accept commands from terminal output, meaning untrusted output could potentially execute commands as the current user. Kitty itself defaults this setting to no; the exposure came from Omarchy explicitly enabling it so other parts of the desktop could query the active terminal’s working directory.

The change disables remote control by default and migrates existing explicit yes settings to no. Users affected by the migration need to fully close and reopen Kitty, as existing processes remain exposed until they exit.

There is a small trade-off: Omarchy can no longer reliably determine the active Kitty tab/pane’s working directory via its socket, so new terminal or Files launches may occasionally fall back to the home directory.

The associated migration tests reportedly pass, although no live Kitty test was run in the test environment.

Nextcloud richtig absichern: praktische Sicherheitstipps für den eigenen Server


Nextcloud sicher betreiben: Updates, HTTPS, 2FA, Reverse Proxy, Brute-Force-Schutz, Fail2ban, Backups und wichtige Server-Einstellungen verständlich erklärt.

Überarbeitet am 8. September 2026.

Eine eigene Nextcloud ist praktisch, aber sie hängt bei vielen von uns direkt am Internet. Damit reicht es nicht, Nextcloud einmal zu installieren und danach jahrelang nicht mehr anzufassen. Zum Glück bringt Nextcloud inzwischen schon viele sinnvolle Schutzmechanismen mit. Ein paar Dinge muss man als Administrator trotzdem selbst sauber einstellen.

Ich gehe hier bewusst nicht in Richtung Hochsicherheits-Rechenzentrum. Es geht um die Maßnahmen, die bei einer selbst gehosteten Nextcloud auf einem Linux-Server wirklich etwas bringen und die man auch dauerhaft pflegen kann.

Table of Contents
Toggle

1. Nextcloud, Apps und Server aktuell halten


Der wichtigste Punkt ist gleichzeitig der langweiligste: Updates. Nextcloud selbst, installierte Apps, PHP, der Webserver und das Betriebssystem sollten regelmäßig aktualisiert werden. Gerade bei öffentlich erreichbaren Diensten werden Sicherheitslücken früher oder später auch automatisiert gescannt.

Nach einem Nextcloud-Update schaue ich deshalb immer in Administrationseinstellungen → Übersicht. Dort meldet Nextcloud fehlende Datenbankindizes, Sicherheitsheader oder andere Probleme, die nach einem Versionswechsel auftauchen können.

2. HTTPS ist Pflicht


Eine Nextcloud sollte öffentlich ausschließlich über HTTPS erreichbar sein. Ein gültiges TLS-Zertifikat gibt es zum Beispiel kostenlos über Let’s Encrypt. Unverschlüsseltes HTTP sollte auf HTTPS umgeleitet werden.

Zusätzlich empfiehlt Nextcloud HSTS. Bei Nginx kann das zum Beispiel so aussehen:
add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;Code-Sprache: JavaScript (javascript)
Achtung: includeSubDomains solltest du nur verwenden, wenn wirklich alle Subdomains deiner Domain per HTTPS funktionieren. Das optionale HSTS-Preloading würde ich erst aktivieren, wenn du genau weißt, welche Folgen das hat – ein Zurücknehmen kann lange dauern.

3. Zwei-Faktor-Authentifizierung aktivieren


Ein starkes Passwort ist gut. Noch besser ist ein zweiter Faktor. Nextcloud unterstützt unter anderem TOTP-Apps und je nach Einrichtung auch WebAuthn beziehungsweise Sicherheitsschlüssel.

Für Administratorkonten würde ich 2FA auf jeden Fall aktivieren. Für Apps oder ältere Clients, die keinen zweiten Faktor abfragen können, verwendet Nextcloud eigene App-Passwörter. Damit muss das normale Kontopasswort nicht in jedem Client hinterlegt werden.

4. Brute-Force-Schutz nicht abschalten


Nextcloud bringt bereits einen eingebauten Brute-Force-Schutz mit. Wiederholte fehlerhafte Anmeldungen werden gedrosselt beziehungsweise blockiert. Dieser Schutz ist standardmäßig aktiv und sollte auch aktiv bleiben.

Wichtig wird das bei einem Reverse Proxy: Nextcloud muss die echte IP-Adresse des Besuchers erkennen. Sind trusted_proxies und die Weiterleitung der Client-IP falsch eingerichtet, sieht Nextcloud möglicherweise nur die Adresse des Reverse Proxys. Im schlechtesten Fall wird dann der gesamte Verkehr so behandelt, als käme er von einer einzigen IP.

5. Fail2ban als zusätzliche Schutzschicht


Zusätzlich zum eingebauten Schutz kann Fail2ban sinnvoll sein. Dabei werden wiederholte fehlgeschlagene Anmeldungen aus dem nextcloud.log erkannt und die betreffende IP bereits auf Betriebssystemebene geblockt. Dadurch müssen Webserver, PHP und Nextcloud diese Verbindungen gar nicht erst weiterverarbeiten.

Die offizielle Nextcloud-Dokumentation enthält dafür inzwischen ein eigenes Filter- und Jail-Beispiel. Wichtig ist, den Pfad zum eigenen nextcloud.log korrekt einzutragen und den Filter nach der Einrichtung wirklich zu testen.

6. Datenverzeichnis außerhalb des Webroots


Nextcloud empfiehlt, das Datenverzeichnis außerhalb des Webroots zu platzieren. Bei einer neuen Installation sollte man das direkt berücksichtigen. So liegen die eigentlichen Nutzerdaten nicht irgendwo unterhalb eines öffentlich ausgelieferten Webverzeichnisses wie /var/www.

Bei einer bestehenden Installation sollte man allerdings nicht einfach den Pfad in der config.php ändern und die Dateien verschieben. Dafür habe ich meine alte Anleitung inzwischen ebenfalls überarbeitet: Nextcloud-Datenverzeichnis sicher verschieben.

7. Debug-Modus auf Produktivsystemen ausschalten


In einer produktiven Nextcloud sollte debug nicht aktiviert sein. Der Debug-Modus ist für gezielte Fehlersuche und Entwicklungsumgebungen gedacht, nicht für den Dauerbetrieb eines öffentlich erreichbaren Servers.

8. SSH und den Linux-Server absichern


Auch die beste Nextcloud-Konfiguration bringt wenig, wenn der Server darunter offen wie ein Scheunentor ist. Für SSH nutze ich deshalb lieber Schlüssel statt Passwort-Anmeldung. Direkter Root-Login sollte deaktiviert werden, sobald ein funktionierender Benutzer mit sudo-Rechten vorhanden und getestet ist.

Eine Firewall sollte nur die Ports freigeben, die tatsächlich benötigt werden. Bei einem typischen öffentlich erreichbaren Server sind das beispielsweise HTTPS und gegebenenfalls SSH. Datenbank-Ports gehören normalerweise nicht offen ins Internet.

9. Backups gehören zur Sicherheit dazu


Ein Backup verhindert keinen Angriff, aber es entscheidet oft darüber, ob ein Fehler oder kompromittiertes System eine Katastrophe wird. Zu einer vollständigen Nextcloud-Sicherung gehören mindestens die Konfiguration, das Datenverzeichnis und die Datenbank. Bei eigenen Apps und Themes müssen auch diese berücksichtigt werden.

Wichtig ist nicht nur, dass irgendein Backup-Job grün leuchtet. Eine Wiederherstellung sollte zumindest gelegentlich getestet werden. Sonst merkt man den Fehler im Sicherungskonzept ausgerechnet dann, wenn man die Daten wirklich braucht.

10. Die Admin-Übersicht regelmäßig ansehen


Mein einfachster Tipp zum Schluss: Öffne regelmäßig die Administrationsübersicht deiner Nextcloud. Die dortigen Sicherheits- und Einrichtungswarnungen sind keine Dekoration. Nextcloud erkennt inzwischen erstaunlich viele typische Fehlkonfigurationen selbst und sagt ziemlich genau, was noch fehlt.

Wer diese Punkte umsetzt, hat schon eine ziemlich solide Basis: aktuelle Software, HTTPS, 2FA, funktionierender Brute-Force-Schutz, ein abgesicherter Server und brauchbare Backups. Viel wichtiger als zwanzig exotische Härtungstricks ist, dass diese Grundlagen dauerhaft gepflegt werden.

Weiterführend: Nextcloud Hardening and Security Guidance und Nextcloud Backup-Dokumentation.

This entry was edited (yesterday, 7:51 PM)

SlowTVStitchery - Episode19


Episode 19 of SlowTV Stitchery, in which we consider flyaway thread, and the importance of writing things down.

When Worlds COLLIDE (Outer Wilds RANDOMIZER ANY% Playthrough)


0:00 Coming Up/Intro
0:58 Timber Hearth/Attlerock
8:00 Brittle Hollow
14:17 White Hole Station and Beyond
15:27 A Fool Out of Air!
16:30 Timber Hearth/Attlerock
17:38 Hourglass Twins
22:01 Go With God
23:07 Giant's Deep
30:32 Twin Impact!
30:55 Timber Hearth
31:58 Hourglass Twins
36:49 Why Does This Keep Happening to Me?
37:27 Timber Hearth
37:49 Hollow's Lantern/Brittle Hollow
40:17 Giant's Deep
41:25 Moon
42:42 Sun Station Smash
44:04 Deep Space Impact!
44:48 Dark Bramble
46:41 Giant's Deep (Whoa...)
49:25 When Worlds Collide
53:59 Interloper (Success!)
56:16 Status Check
56:42 Brittle Hollow
59:55 Brittle Bash!
1:00:13 Timber Hearth
1:01:24 Giant's Deep
1:02:15 Hourglass Twins
1:02:55 Moonscan
1:03:30 Home Stretch (Watch for Fishies)

!SPOILER WARNING!
If you haven't played Outer Wilds or its associated DLC "Echoes of the Eye," please do NOT watch this video (or any other) until you have. Outer Wilds is a game of discovery in the most rewarding way. Once you have that knowledge, a core part of the game can never be experienced again. It's such a blast to play, and I guarantee you'll thank yourself for doing so.

With that out of the way, welcome to my Archipelago Randomizer challenge! The aim with this attempt is to complete enough of the 87 randomized checks scattered throughout the solar system to help me warp to the Eye of the universe and finish it off, all in one session! These checks cover virtually every location within the base game. To clarify, the items/abilities obtained from the checks are random (as are other aspects of the game, such as shuffled ghost matter), but the locations of the checks are not (e.g. a random item/ability is always found* when reading the second scroll in the Construction Yard on Giant's Deep).
*There can also be traps laid in a check, such as sudden ship damage or a suit puncture.

So, what's an Archipelago Randomizer? From the mod page:
"Randomizers in the Archipelago sense—which are sometimes called 'Metroidvania-style' or 'progression-based' randomizers—rely on the base game having several progression-blocking items you must find in order to complete the game. In Outer Wilds progression is usually blocked by player knowledge, so to make a good randomizer we take away some of your starting equipment (Translator, Scout, Signalscope, etc), and turn much of that player knowledge into items (using warp platforms now requires a 'Nomai Warp Codes' item, using the special GD tornado now requires a 'Tornado Aerodynamic Adjustments' item, etc.). These 'items' are then placed at randomly selected 'locations' while ensuring the game can still be completed."

I normally incorporate the following rules: no map, no hints, no ship log, no meditation, and no velocity matching. However, this time all is fair game, as this is an "ANY%" run. In addition to that, I'll have specific mods applied, such as a certain "strange" large structure now visible in the sky so I don't accidentally run into it (again).

Finally, a big thank you to the great minds at Mobius Digital for developing such a stellar game and to the many contributors in the modding community for creating the perfect excuse for me to revisit the fun physics of this clockwork solar system! Check out the links below for more info on the game and mods:

Outer Wilds - Steam Store

Outer Wilds - Mobius Digital

Archipelago Randomizer

This entry was edited (yesterday, 1:59 AM)

The Influence of Tire Typology on Pyrolysis Efficiency and Product Yield Dynamics


Scrap tire recycling via thermal pyrolysis represents a critical engineering frontier for mitigating global elastomer waste. However, industrial operators frequently encounter operational inefficiencies when processing heterogeneous feedstock streams. Scrap tires are far from uniform; they vary dramatically by vehicle classification, manufacturing origin, structural reinforcement, and chemical compounding. Passenger car tires, commercial truck tires, and specialized off-the-road tires possess distinct morphological and chemical profiles that directly dictate pyrolytic heat transfer rates, volatile matter evolution, and the ultimate yield distribution of pyrolytic oil, recovered carbon black, and steel wire.

Elastomer Blends and Macromolecular Pyrolysis Kinetics


The core of any tire matrix comprises a complex blend of synthetic and natural elastomers, primarily natural rubber, styrene-butadiene rubber, and polybutadiene. Each polymeric constituent exhibits distinct thermal degradation kinetics and volatilization thresholds. Natural rubber undergoes thermal cleavage at lower temperature intervals, yielding high initial volatile fractions, whereas synthetic styrene-butadiene copolymers require elevated thermal plateaus to achieve complete depolymerization.

Consequently, tires with high natural rubber content decompose more rapidly under initial heating in pyrolysis machine, whereas heavy-duty truck tires—which heavily utilize synthetic blends for enhanced tread wear resistance—demand extended residence times and higher peak reactor temperatures to prevent incomplete thermal cracking and residual heavy tar accumulation.

Reinforcement Architecture and Thermal Conduction


Beyond polymer chemistry, the internal physical architecture of a tire exerts a profound influence on reactor thermodynamics. Passenger car tires typically feature high textile cord content and lighter steel belts, whereas heavy commercial vehicle tires incorporate dense, multi-ply steel wire matrices.

Steel Content and Thermal Conductivity Variations


The presence of substantial steel fractions alters the bulk thermal conductivity of the charge. Steel acts as a localized thermal conductor, accelerating heat penetration into the center of the shredded tire matrix. However, an excessive accumulation of unseparated steel wire inside a continuous tyre pyrolysis plant can cause mechanical wear, bridge feeding mechanisms, and interfere with uniform bed temperatures. Furthermore, the metal fraction absorbs thermal energy without undergoing volatilization, shifting the mass balance calculations and requiring careful calibration of the energy inputs supplied to the primary pyrolytic reactor.

Compounding Additives and Mineral Filler Impacts


Tire manufacturing involves intensive chemical compounding, incorporating reinforcing fillers such as commercial carbon black, mineral silica, sulfur vulcanizing agents, and metallic oxides like zinc oxide. These inorganic additions do not vaporize during the thermal degradation phase; instead, they concentrate entirely within the solid residue, fundamentally altering the quality of the recovered carbon black.

High-silica passenger tires yield a solid residue contaminated with amorphous silicon dioxide, which limits its direct reinjection into high-performance rubber compounding without prior acid leaching or chemical beneficiation. Conversely, heavy truck tires with high carbon black loadings produce a more structurally robust solid residue that, with proper mechanical milling and pelletization, achieves high market valorization.

Volatile Fraction Condensation and Liquid Oil Specification


The chemical composition of the input tire type directly dictates the boiling range and heteroatom concentration of the resulting pyrolytic oil. Passenger tires, containing varied plasticizers and synthetic rubber formulations, generate a highly complex liquid condensate rich in aromatic hydrocarbons, sulfur compounds, and nitrogenated molecules. This requires sophisticated multi-stage fractional distillation and catalytic hydrotreatment to remove contaminants before the oil can be co-processed in conventional refineries. Heavy truck tires, dominated by different vulcanization packages, yield distinct boiling curve distributions that necessitate precise dew-point control within the condensation train to prevent pipe fouling and coking.

Tailoring Operational Parameters for Feedstock Variability


The inherent variability among tire typologies necessitates flexible, highly responsive operational parameters within commercial pyrolysis facilities. Operators cannot apply a static temperature profile or uniform residence time to a mixed batch of passenger and truck tires. Optimizing thermal efficiency requires rigorous pre-sorting, mechanical size reduction, and feed-stream homogenization. By categorizing incoming scrap tires by vehicle classification and structural composition, facility managers can fine-tune reactor heating ramps, optimize syngas recovery trains, and maximize the commercial value of both liquid condensates and solid carbonaceous outputs, securing long-term economic resilience in the competitive chemical recycling sector.

Bluefin Server — Cloud-native home infrastructure from Project Bluefin


in reply to eldavi

Yes is is.

fmd-foss.org/docs/fmd-server/o…

They have a public instance you can use but if you're going to have things like location tracking and device wipe enabled then it's probably better to self host.

Community Camp 4 Palestine 06.09.2026


The Community Camp 4 Palestine marked 2 years of being there 24/7, directly opposite the American Embassy... A constant protest against America's complicity and enabling of Israel's genocide in Palestine... A powerful day and I was blown away to meet Dr Ang Swee Chai... A woman I have maximum respect for... 44 years working as a surgeon for the people of Palestine... The video is rough and ready, unedited but worth watching .

Thermodynamic and Harmless Valorization of Municipal Sludge via Pyrolytic Treatment


Municipal wastewater treatment facilities generate astronomical volumes of dewatered sludge daily, presenting an escalating logistical and ecological challenge. Comprising complex organic matrices, pathogenic microorganisms, heavy metals, and persistent trace pollutants, raw sludge resists safe long-term containment. Traditional management pathways, including direct agricultural application, landfilling, and conventional incineration, face tightening regulatory constraints due to groundwater contamination risks, greenhouse gas emissions, and toxic ash management burdens. In response to these vulnerabilities, industrial pyrolysis—defined as the thermal degradation of carbonaceous matter in an oxygen-depleted environment—emerges as a premier engineering paradigm for harmless disposal and resource valorization.

The Imperative of Advanced Municipal Sludge Sanitization


Ensuring total pathogen destruction and the elimination of emerging organic contaminants is the foundational requirement for any municipal sludge management protocol. Conventional biological stabilization techniques frequently fail to eradicate resilient pharmaceutical residues, endocrine-disrupting chemicals, and pathogenic spores completely. Thermochemical processing bridges this critical performance gap. Exposing the sludge matrix to elevated temperatures eradicates biological activity entirely, instantly decomposing volatile organic compounds and thermal-sensitive pollutants. This complete sanitization shifts the operational framework from hazardous waste containment to sustainable material transformation.

Thermochemical Mechanisms and Reactor Kinetics


The execution of sewage sludge treatment plant with pyrolysis technology relies on precise thermodynamic control within specialized industrial equipment, such as indirect-fired rotary kilns, fluidized beds, or continuous screw conveyors. Operating typically within a temperature threshold of 450 degrees Celsius to 850 degrees Celsius, these reactors supply the necessary thermal energy to drive the endothermic cleavage of high-molecular-weight polymers, including proteins, lipids, and humic substances. Because the reactor operates under sub-stoichiometric or completely inert conditions, complete combustion is prevented. Instead, the reaction kinetics favor devolatilization, carbonization, and structural aromatization, yielding three distinct product streams: a stable solid carbonaceous residue, condensable bio-oil, and non-condensable syngas.
Biochar Machine

Volatilization and Carbon Matrix Encapsulation


As thermal energy transfers through the moist sludge matrix, interstitial water is rapidly vaporized, paving the way for thermal cracking of organic fractions. The volatile gases escape the solid phase and are subsequently captured or condensed, while the remaining solid fraction undergoes severe volumetric shrinkage. This process forms a dense, highly stable pyrolytic char. Crucially, inorganic mineral phases and heavy metals—such as chromium, nickel, lead, and cadmium—are chemically and physically encapsulated within the expanding carbon lattice. This structural entrapment drastically suppresses their environmental mobility and leachability, neutralizing the primary ecological hazard associated with raw sludge disposal.

Environmental Abatement and Heavy Metal Stabilization


Atmospheric protection and leachate mitigation represent core advantages of pyrolytic treatment over traditional incineration. Because pyrolysis avoids the oxygen-rich combustion environment characteristic of incinerators, the formation of noxious sulfur dioxide and nitrogen oxides is profoundly suppressed. Furthermore, volatile inorganic compounds and condensable tars are routinely captured within integrated scrubbing systems or thermally destroyed inside secondary reaction chambers. This inherent emission control architecture bypasses the requirement for capital-intensive flue gas cleaning trains, offering municipal authorities a compliant, streamlined operational profile. The resulting solid residue, exhibiting negligible leachability under standardized testing protocols, eliminates long-term sub-surface liabilities.

Energetic Autonomy and Resource Recovery


Beyond environmental decontamination, industrial pyrolysis achieves exceptional thermodynamic efficiency through internal energy recovery loops. The non-condensable gases generated during thermal cracking—comprising hydrogen, carbon monoxide, methane, and light hydrocarbons—possess significant calorific value. By scrubbing and recirculating this syngas to feed the primary thermal reactor or power auxiliary mechanical drives, the facility achieves operational energetic autonomy. This closed-loop configuration neutralizes the massive thermal energy penalties typically incurred during the preliminary drying of high-moisture municipal sludge. By converting a persistent environmental liability into a secure geomaterial and a reliable energy source, pyrolysis establishes an indispensable foundation for advanced municipal resource recovery.

Zenless Zone Zero - Is the Shiyu reset as hard as it seems?


Peertube LiveChat Plugin

This entry was edited (yesterday, 2:45 AM)

Latin American Local Assembly vs Chinese Import Which Model Truly Reduces Your Initial Procurement Price


In the competitive road and bridge construction industry across Latin American markets, securing reliable machinery while controlling capital expenditure is a constant challenge. Project contractors and equipment dealers frequently face a tough decision when sourcing new production units: should you invest in a equipment locally assembled within Latin America, or should you import a complete plant directly from Chinese manufacturers? While both options have distinct advantages, understanding how each model affects your upfront capital output is essential for making a sound financial investment.

To make an informed purchasing decision, contractors must carefully evaluate every factor that contributes to the final price tag. The initial acquisition cost encompasses not just the factory base quote, but also international shipping rates, import duties, assembly labor, and regional supply chain factors. By breaking down these cost components, contractors can accurately determine which sourcing strategy delivers the best value for their specific operational needs and budgetary limits.

Analyzing the Base Asphalt Plant Price Breakdown


When comparing local assembly against direct imports, the base asphalt plant price(precio de planta de asfalto) remains the primary benchmark for budget planning. Chinese manufacturers benefit from massive economies of scale, extensive supply chain networks, and lower raw material procurement costs. As a result, direct factory quotes for complete imported systems often come in significantly lower than local assembly alternatives.

Local assembly facilities in Latin America typically import key technological components—such as burners, control software, and high-precision sensors—from global suppliers, while fabricating heavier structural elements like aggregate bins, dryer drums, and frame supports locally. Although this hybrid approach reduces international freight volume, higher local steel prices and smaller production runs can elevate the base production cost. Consequently, the ex-factory asphalt plant price for locally assembled units often reflects higher manufacturing overhead compared to direct Chinese imports.

Import Tariffs and Custom Duties Impact


Customs duties and trade agreements play a pivotal role in shaping the final landed equipment cost across Latin American countries.


  • Trade agreements: Regional trade pacts can make locally assembled machinery more appealing if components move tax-free between partner nations.
  • Tariff variations: Direct imports from China may face varying tariff brackets depending on the destination country, sometimes adding a noticeable percentage to the total outlay.
  • Tax incentives: Certain infrastructure initiatives offer temporary import tax exemptions for complete machinery, offsetting potential tariff penalties.

Understanding these trade dynamics helps contractors calculate whether local assembly tax perks outweigh the lower base price of direct imports.

Total Investment for Compact and Portable Systems


For short-term projects, urban road repairs, or remote bridge access roads, contractors often prefer smaller or movable setups. Evaluating the mobile asphalt plant price(planta de asfalto móvil precio) requires looking beyond the sticker price to account for freight and logistics complexities.

Cost FactorChinese Direct ImportLatin American Local Assembly
Base Manufacturing CostLower due to scaleHigher due to component imports
Shipping & LogisticsHigher overseas freight feesLower local transportation fees
Delivery TimetableLonger transit timeFaster regional delivery
Customization OptionsStandardized modular designsTailored regional adaptations

Mobile Units Freight and Mobility Logistics


Transporting fully mobile equipment involves shipping multi-axle chassis, towing mechanisms, and compact mixing units across ocean routes. While Chinese suppliers offer highly competitive initial machinery costs, long-distance maritime freight and heavy-lift handling fees can inflate the final delivered mobile asphalt plant price. Conversely, local assembly plants can deliver portable units directly by road, cutting down international shipping expenses and simplifying overall transport logistics.

Mini Units for Targeted Projects


For niche applications requiring modest output, a mini asphalt plant(mini planta de asfalto) provides an economical entry point for small-to-midsize contractors.


  1. Reduced capital expenditure: Small-capacity mixing units require significantly less initial capital, lowering the barrier to market entry.
  2. Faster installation: Compact designs mean minimal foundation work and rapid setup times on bridge decks or narrow site paths.
  3. Lower shipping volume: Small footprints allow a mini asphalt plant to fit inside standard container units, drastically cutting ocean transport costs for Chinese imports.

Because smaller equipment fits standard ocean containers, buying a compact system from overseas often preserves the low base price advantage without incurring excessive heavy-cargo shipping surcharges.

Key Considerations Beyond the Initial Price Tag


While upfront cost is a decisive factor, equipment long-term value depends on operational reliability, spare parts availability, and technical support.

Component Quality and Engineering Standards


Chinese machinery producers have made substantial advancements in build quality, leveraging automated welding, precise laser cutting, and standardized modular manufacturing. Meanwhile, regional Latin American assemblers often tailor structural designs specifically for local aggregate conditions and rugged terrain, which can enhance equipment longevity in demanding environments.

After-Sales Service and Spare Parts Availability


  • Local support: Regional assembly plants usually offer faster technician response times and immediate access to replacement parts stocked domestically.
  • Digital support: Leading export suppliers provide 24/7 remote diagnostic assistance and maintain regional distribution hubs to dispatch critical components quickly.

Contractors must weigh the convenience of immediate local service against the overall cost savings offered by direct overseas purchasing.

Making the Final Sourcing Determination for Your Project


Choosing between local assembly and direct importing ultimately comes down to your project timeline, overall budget, and logistics capabilities. Importing directly from Chinese manufacturers generally yields a lower base asphalt plant price, especially for containerized units and small-scale machinery where shipping costs remain manageable. On the other hand, local assembly models offer advantages in delivery speed and local regulatory compliance, though often at a higher initial capital outlay.

By analyzing the full picture—including the mobile asphalt plant price, freight logistics, customs tariffs, and site requirements—contractors can choose the model that delivers maximum cost efficiency for their asphalt production operations. For contractors looking to maximize profitability on limited bridge and road construction budgets, opting for a high-efficiency mini asphalt plant or standard imported unit remains one of the most effective strategies to lower initial procurement expenses.

When Living the Dream Becomes a Nightmare


Beautiful wife, two kids, family pet. All gone because she went back to college.
#Redonkulas #ModernWomen #CultureWar

To donate to this content, see our list of channels, purchase merchandise or join Popp’s Preppers, click here: linktr.ee/redonkulas

Send physical donations to:
Redonkulas.com Productions
29488 Woodward Avenue, Unit 407
Royal Oak, MI 48073
If you write a check, make it out to Second Class Citizen, 501c3
All donations are tax deductible

And be sure to tune in to see the Redonkulas Regiment Live!
Tuesday and Thursday at 8pm Eastern time!
And
Supporter Sunday streams for Locals, Odysee, and SubscribeStar members only!

All sources available on Redonkulas.com!

This entry was edited (yesterday, 8:51 PM)

Is there a way to hide/remove categories shown in the categories tab of the app?


Pretty much what the title implies. I enjoy the feature itself and find it useful for browsing and discovering applications on F-Droid that I didn't know existed, but there are certain categories of applications that I have no use for and would find it easier to filter them out rather than ignore.

Breaking News (Sun May 28 16:38:01 GMT 2023)


in reply to Acta Populi

Finding the right answer might get harder as players try to reduce the options, even though the fundamental idea is simple to grasp. wordle hint today

Koa's little mud bath 😂 06/09/2026


A video capturing a joyful and wonderfully messy moment at the Herperduin, featuring Koa, a handsome and energetic young chocolate brown Labrador Retriever pup. Koa, sporting his signature small strip of white fur right in the middle of his chest, is happily trotting along the sandy shore on a light blue leash held by Yolande. Cynni is walking behind them, acting as the videographer and capturing all the action as they film the scenic walk.
Because the pond is quite low from a dry summer, the recent rains have created a gloriously thick, squishy border of mud along the water's edge. Unable to resist the allure of the muck and an abandoned ball, he enthusiastically marches right off the dry sand and plunges his paws straight into the deep, wet mud, his tail wagging with pure delight. Yolande carefully navigates the slippery bank, keeping pace with the eager pup while jokingly calling him a "smeerkees". Koa happily splooshes through the shallows, thoroughly investigating the mud and treating himself to a very enthusiastic, messy spa day. Cynni follows along, making sure this hilarious adventure is perfectly documented for the memories.
This entry was edited (Monday, September 7, 2026, 1:58 AM)

Koa's snack attack! 05/09/2026


The video opens with Koa, a handsome, chocolate brown Labrador Retriever puppy, lounging comfortably in his cozy, light-green dog bed on a wooden floor. He is happily and diligently gnawing on a brand new, large, pale chew stick, completely absorbed in his treat. A small blue toy sits ignored nearby on the floor. Cynni is filming the peaceful scene, capturing his young puppy energy focused entirely on enjoying his delicious snack.
​Suddenly, his attention shifts. Koa looks up directly at the camera, his bright, loving eyes locking onto Cynni. With the giant chew stick still held proudly in his mouth like a prized trophy, he scrambles up from his bed. He trots enthusiastically straight toward the camera. The video ends in a hilarious and heartwarming "snack attack" as Koa shoves his sweet, goofy face and his beloved chew stick directly into the camera lens, playfully showering Cynni with puppy love and giving them a very close-up view of his new treasure.
This entry was edited (Monday, September 7, 2026, 4:10 AM)

I changed my license


cross-posted from: feddit.org/post/35110129

This year I decided to switch my “default license” to EUPL-1.2. This is an OSI-approved free software license created and published by the European Union. And it is quite a divergence from the licenses I’ve used in the past. EUPL is a strong copyleft license that closes the “SaaS loophole” by requiring reciprocal licensing regardless of how the software is distributed.

Over the years it has been clear that we in the “open source” camp (as opposed to the “free software” camp) were wrong all along.

We won the debate, and gained little for users or developers. All that our efforts did was to make it easier for big corporations build things more cheaply and for billionaires to become trillionaires.

And so it is time to stop messing about with permissive licenses. If corporations don’t want to use our software under our terms, they are free to spend the effort or tokens to build their own.


don't like this