Stora ownCloud/Nextcloud-tråden

Den har dock samma problem utan PHP-FPM, men lite snabbare genereringar blir det kanske..

Och nu har de integrerat chatgpt och ai-bildgenerering.. it never ends

Har några frågor till dig @enoch85 eller andra i tråden:
Jag har för några dagar sedan försökt få igång Nextcloud. Först försökte jag få igång den genom ubuntu+docker men fastnar på det här med domännamnet. Vad ska man skriva där om man bara vill testköra den i Virtualbox?

Testade också att ladda ner Nextcloud VM 40Gb till Virtualbox men den säger att det inte finns någon bootbar disk.Testade bocka för vdi-disk också i importen.
Testade för några år sedan att få igång Nextcloud, då lyckades jag men nu lyckas jag inte.

Finns det några bra guider som man lätt kan få igång en testversion som man kan utvärdera. Tänkte se om jag kunde skippa Onedrive nästa år när man ska förnya pren.

Du kan skriva ditt lokala IP som domännamn.
En bra guide som funkar för mig även på Debian:
https://www.linode.com/docs/guides/how-to-install-nextcloud-o...

Vet inte om din host kör Linux, men om den kör Linux så är ett tips att börja använda Qemu istället för Virtualbox. Qemu är lite krångligare om man är van vid Virtualbox, men när man väl fått det att funka så undrar man varför man använde Virtualbox. Quemu är sjutton gånger snabbare.

Tack för svar. När jag provade och kom till den inställningen där man ska skriva domännamn så skrev jag ip-numret och den klagade och sa jag inte fick använda ip-nummer. Men ska prova igen och kolla på den guiden.

Jag kör Win i grunden och leker mycket med virtualbox och olika distar. Tanken kanske i framtiden är att sätta upp en NUC igen med Proxmox och olika system, därför jag vill utvärdera hur bra nextcloud fungerar.

Skulle verkligen underlätta om jag fick igång Hanssons färdiga installation, den vet jag var enkel att installera.

Jag löste det sedan, tack så mycket för hjälpen

Har behövt att installera om hela min server efter en disk gått sönder och bestämde mig för att gå över från Ubuntu server till Debian. Har haft en guide jag alltid utgått ifrån när jag ska installera Nextcloud. Givetvis så är det en hel del som inte fungerat. Har löst alla problem förutom Redis Memory caching. Har kollat igenom en massa guider inklusive min egen, men ingen av dem har fungerat.

Har inte så mycket tålamod med såna här saker längre som jag hade när jag var ung, så jag pallar inte mer. Att sitta en hel helg får räcka.

Jag har detta som en varning i mitt Nextcloud:

The database is used for transactional file locking. To enhance performance, please configure memcache, if available. See the documentation  for more information.

Frågan är, behöver jag bry mig om detta eller kan jag skippa det? Vet egentligen inte vad Redis gör och om jag behöver det. Vi är bara två som använder Nextcloud så om det endast har med prestanda att göra kanske vi klarar oss utan Redis?

Kort och gott så är varningen att MySQL kommer användas för transactional file locking istället för redis så all funktionalitet finns kvar, men file locking innebär många små och snabba läs/skriv som inte behöver vara långlivade (datan är bara kvar medan en fil aktivt används) så redis kan lösa det mer effektivt.

Det är, precis som det står, för prestandans skull så är ni nöjda så är det ju en komponent mindre ni behöver tänka på om ni kör utan.

Efter min ominstallation av servern har jag i alla klienters root fått dessa filer i både Windows och Linux klienter:

.nextcloudsync.log
.sync_62bd2a8039cd.db
.sync_62bd2a8039cd.db-shm
.sync_62bd2a8039cd.db-wal
.sync-exclude.lst

Har inte tänkt på om de alltid har funnits där i tidigare versioner av Nextcloud. Jag prövade att ta bort dem, men då börjar Nextcloud att synka om alla filer.

Tycker att det är lite störande om de behövs och ligger där de ligger. Om de behövs så borde de ligga i en konfig-katalog istället för i klientens root.

Har alla denna typen av filer i klientens rootkatalog?

https://github.com/nextcloud/desktop/issues/2807
Det är dolda filer, men det verkar som att de 'alltid' funnits där.

Brukar det vara någon återkoppling på issues där eller slänger man bara mer på högen av 1217 öppna issues? Verkar vara en procentuellt stor andel som är drabbad av https://github.com/nextcloud/android/issues/11974 och det är ju inte ens en antydan till bekräftelse att man kikar på det.

Hela min karriär är byggd på open source så min fråga var kanske lite mer specifik, om de faktiskt bekräftar buggar någonstans någon gång. Nextcloud är ett av de minst responsiva projekten (av den storleken) som jag vart med om. I synnerhet mobilapparna verkar vara periodvis övergivna med allvarliga buggar som tar månader att lösa (om de ens någonsin löses).

Och det är väl fine, men det är enerverande att de aldrig bekräftar att ett fel existerar eller jobbas på. Total tystnad tills det löses eller de drabbade användarna migrerat iväg..

De har tydligen redan testat den idén men det skapade problem.

Det är tokigt att filerna ligger där i vilket fall. En okunnig användare kan undra vad det är för filer (eftersom de själva inte lagt dem där) och sen tar bort dem.

jaha, har börjat få nåt konstigt varningsmeddelande i admin-panelen:

Vad jag läst kan detta bero på att dessa headers är konfigurerade på flera ställen. Men vad jag hittar så är de endast omnämnda i .htaccess i nextcloud-mappen, som är inkluderad under konf i /etc/apache2/sites-enabled. Började få dessa felmeddelanden efter uppgradering till Nextcloud 27.

  <IfModule mod_env.c>
    # Add security and privacy related headers

    # Avoid doubled headers by unsetting headers in "onsuccess" table,
    # then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
    Header onsuccess unset Referrer-Policy
    Header always set Referrer-Policy "no-referrer"

    Header onsuccess unset X-Content-Type-Options
    Header always set X-Content-Type-Options "nosniff"

    Header onsuccess unset X-Frame-Options
    Header always set X-Frame-Options "SAMEORIGIN"

    Header onsuccess unset X-Permitted-Cross-Domain-Policies
    Header always set X-Permitted-Cross-Domain-Policies "none"

    Header onsuccess unset X-Robots-Tag
    Header always set X-Robots-Tag "noindex, nofollow"

    Header onsuccess unset X-XSS-Protection
    Header always set X-XSS-Protection "1; mode=block"

    SetEnv modHeadersAvailable true
  </IfModule>

  <IfModule mod_env.c>
    # Add security and privacy related headers

    # Avoid doubled headers by unsetting headers in "onsuccess" table,
    # then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
    Header onsuccess unset Referrer-Policy
    Header always set Referrer-Policy "no-referrer"

    Header onsuccess unset X-Content-Type-Options
    Header always set X-Content-Type-Options "nosniff"

    Header onsuccess unset X-Frame-Options
    Header always set X-Frame-Options "SAMEORIGIN"

    Header onsuccess unset X-Permitted-Cross-Domain-Policies
    Header always set X-Permitted-Cross-Domain-Policies "none"

    Header onsuccess unset X-Robots-Tag
    Header always set X-Robots-Tag "noindex, nofollow"

    Header onsuccess unset X-XSS-Protection
    Header always set X-XSS-Protection "1; mode=block"

    SetEnv modHeadersAvailable true
  </IfModule>

Kolla om du har:

Header set X-Content-Type-Options: "nosniff" 
Header set X-Frame-Options: "sameorigin"

I både:
/etc/apache2/conf-available/ssl-params.conf
och
/etc/apache2/conf-available/security.conf

Kommentera i så fall bort dessa två rader i:
/etc/apache2/conf-available/ssl-params.conf

Tror det ska lösa ditt problem.

Edit:
Har du inte ssl-params.conf så kan du kommentera bort dessa rader i security.conf

Ser att efter att jag bytt till Debian och installerat allt på nytt så har jag inte filen ssl-params.conf.

@Eazy har endast filen security.conf och där är båda raderna utkommenterade.

Hmm, då har jag ingen lösning. Hade ditt bekymmer för några år sedan så var därför jag föreslog det.
Googlade lite och någon kommenterade bort det ur htaccess, men den lösningen känns lite sådär... Man vill ju gärna veta i vilken fil det mer är satt i.

Jo men precis! Har försökt hitta vart mer det kan stå, men inte fått fram nåt svar på det.

sudo grep -r nosniff /etc/apache2

Jaa, joo. Det visar dock bara tidigare nämnda security.conf där det är utkommenterat.

Finns det något mer ställe där det kan finnas?

Du överkomplicerar det inte bara? Är mod_env enabled? I annat fall så sätts ju inte värdena så att felmeddelandet kanske är exakt vad det säger att det är..

Japp, både mod_env och mod_headers är aktiverat, enligt dokumentation.