For å løse Wordpress-feilmeldingen: «Oppdateringen kan ikke fortsette fordi noen filer ikke kan kopieres», skyldes dette problemet vanligvis inkonsistente filtillatelser.

Når du vedlikeholder et WordPress- nettsted i HestiaCP -miljøet , kan du støte på feilmeldingen «Oppdatering kan ikke utføres fordi noen filer ikke kan kopieres».

Denne advarselen kan virke alarmerende, men det er faktisk et av de vanligste problemene knyttet til WordPress-tillatelser.

Det skjer vanligvis under automatiske oppgraderinger av plugins, temaer eller WordPress-kjernen.

På overflaten er det bare en «mislykket oppdatering», men den underliggende årsaken peker nesten alltid på det samme: inkonsistente filtillatelser.

Den gode nyheten er at når du forstår HestiaCPs brukermodell, kan du løse problemet fullstendig med bare noen få kommandoer.

Rotårsaken til problemet: Hvorfor oppstår det uoverensstemmelser i tillatelser?

I HestiaCP-miljøet kjører hvert nettsted (Vhost) under en separat systembruker.

I mellomtiden utføres også webtjenesteprosessene (PHP-FPM / Nginx) under systembrukerkontoen som tilsvarer nettstedet.

Derfor, når eieren av noen plugins eller temafiler blir root eller en annen bruker, vil ikke nettstedbrukere ha rett til å endre eller slette disse filene.

Under oppgraderingen må WordPress kopiere og overskrive disse filene. Hvis tillatelsene er feil, vil oppgraderingen bli avbrutt, og meldingen ovenfor vil vises.

Hovedårsaken kan oppsummeres i én setning: fileieren er ikke lenger en bruker av nettstedets system.

Løsning: Reparer filtillatelsene i SSH-terminalen.

Nedenfor finner du de bekreftede reparasjonstrinnene; bare utfør kommandoene sekvensielt i SSH-terminalen.

Vennligst erstatt din_bruker i eksemplet med HestiaCP-brukernavnet ditt, og dittdomene.com med ditt faktiske domenenavn.

Hele prosessen krever ikke at tjenesten startes på nytt, og vil ikke påvirke nettstedets eksisterende data.

Hele prosessen tar omtrent to minutter, og selv nybegynnere kan kjøre den på første forsøk ved å ganske enkelt kopiere og lime inn.

Før du fortsetter, anbefales det å bekrefte at terminalen kan logges på som administrator for å unngå frakobling under prosessen.

Trinn 1: Definer variabler

Først angir du to variabler, brukernavn og domenenavn, i terminalen slik at påfølgende kommandoer kan brukes direkte på nytt.

# 设置你的 Hestia 用户名和域名
HESTIA_USER="your_user"
HESTIA_DOMAIN="yourdomain.com"

Når variablene er definert, kan alle påfølgende kommandoer referere direkte til dem, slik at man unngår behovet for manuell inndata hver gang.

Trinn 2: Gjenopprett fileierskap (kjernereparasjon)

Tving systemeieren og brukergruppen for alle filer i nettstedkatalogen til å returneres til den tilsvarende HestiaCP-brukeren.

chown -R $HESTIA_USER:$HESTIA_USER /home/$HESTIA_USER/web/$HESTIA_DOMAIN/public_html

Dette trinnet er kjernen i hele reparasjonsprosessen; når eierskapsproblemet er løst, er problemet løst.

Hvis chown rapporterer at banen ikke finnes, må du først sjekke om variabelstavingen samsvarer med den faktiske katalogen.

Trinn 3: Tilbakestill standard fil- og katalogtillatelser for HestiaCP

Deretter setter du katalogtillatelsene til 755 og filtillatelsene til 644.

# 修复所有目录权限为 755
find /home/$HESTIA_USER/web/$HESTIA_DOMAIN/public_html -type d -exec chmod 755 {} \;

# 修复所有文件权限为 644
find /home/$HESTIA_USER/web/$HESTIA_DOMAIN/public_html -type f -exec chmod 644 {} \;

Disse to settene med tillatelser er standardkonfigurasjoner for HestiaCP, som samtidig kan tilfredsstille både sikkerhet og skrivbarhet.

Ett-klikks-skript (anbefales)

Hvis du ønsker å fullføre alle operasjonene ovenfor samtidig, kan du bruke følgende ettklikksskript.

Bare erstatt your_user og chenweiliang.com med dine faktiske verdier, lim inn hele avsnittet i terminalen, og trykk Enter.

USER="your_user" DOMAIN="chenweiliang.com" && chown -R $USER:$USER /home/$USER/web/$DOMAIN/public_html && find /home/$USER/web/$DOMAIN/public_html -type d -exec chmod 755 {} \; && find /home/$USER/web/$DOMAIN/public_html -type f -exec chmod 644 {} \;

Ytterligere tips: For å gjøre reparasjonen mer grundig

Å fikse tillatelser løser bare den umiddelbare årsaken til problemet med at oppdateringen sitter fast. For å løse dette problemet fullstendig er det to andre ting som er verdt å gjøre.

Først, rydd opp i gjenværende filer som ble etterlatt av den avbrutte oppgraderingen; for det andre, lær hvordan du utfører bakgrunnsreparasjoner uten å være avhengig av SSH.

Disse to trinnene er ikke vanskelige, men de kan redusere sannsynligheten for at lignende problemer oppstår igjen betydelig.

Følgende operasjoner er alle basert på forutsetningen om at tillatelsene nettopp er gjenopprettet. Å utføre dem i rekkefølge vil gi best resultat.

Hvis du har mer enn ett nettsted på serveren din, kan du også organisere denne prosessen i en skriptmal for gjentatt bruk.

Fjern midlertidige oppgraderingsrester

Etter at du har gjenopprettet tillatelsene, anbefales det å rydde opp i eventuelle midlertidige filer som ble igjen da WordPress-oppgraderingen ble avbrutt.

Disse gjenværende filene ligger i wp-content/upgrade-katalogen. Hvis du ikke fjerner dem, kan det føre til at neste oppgradering stopper opp igjen.

rm -rf /home/$USER/web/$DOMAIN/public_html/wp-content/upgrade/*

Vil du ikke bruke SSH? Fiks det manuelt i HestiaCP-backend.

Hvis du synes det er upraktisk å bruke kommandolinjen, kan du også logge inn på HestiaCP-backend og tilbakestille tillatelser via filbehandleren.

Gå til Filer (filbehandler) og naviger til /home/USER/web/DOMAIN/public_html/wp-content.

Høyreklikk på mappen med programtillegg eller temaer, og velg Tilbakestill tillatelser.

Etter at du har tilbakestilt tillatelsene, går du tilbake til WordPress-administrasjonspanelet og klikker på oppdater igjen. Det skal vanligvis fungere problemfritt.

Hvis den samme feilen vedvarer etter at du har utført backend-operasjonen, går du ganske enkelt tilbake til SSH-løsningen ovenfor og bekrefter eierskapet på nytt.

oppsummering

Hvis du får meldingen «Oppdatering kan ikke utføres fordi noen filer ikke kan kopieres», ikke forhast deg med å installere på nytt. I de fleste tilfeller er det et problem med tillatelser.

Ved å bruke én `chown`-kommando og to `find`-kommandoer for å returnere eierskap og tillatelser, kan WordPress-oppdateringer fullføres problemfritt.

Å utvikle vanen med å sjekke fileierskap før oppgradering kan fundamentalt forhindre at denne typen feil gjentar seg.