Dacă ownCloud afișează mesajul „Verificarea integrității a eșuat” după o actualizare, utilizați raportul fișierelor nevalide pentru a identifica ce a eșuat înainte de a modifica fișierele. O rescanare repetă doar verificarea; nu restaurează fișierele lipsă, nu anulează modificările personalizate și nu instalează o versiune corectată a aplicației. Pentru fișierele de bază, comparați cu versiunea exactă de ownCloud la care ați făcut upgrade. Pentru o problemă de semnătură a aplicației, căutați o actualizare a aplicației compatibilă, semnată corect sau contactați administratorul acesteia.
Reparația corectă depinde de amploarea avertismentului. Înlocuirea unei instalații întregi poate fi mai sigură după o actualizare parțială sau cu versiuni mixte, dar necesită mai mult timp de nefuncționare și o conservare atentă a datelor de configurare și de utilizator. Înlocuirea unui fișier principal confirmat este mai rapidă, dar numai atunci când puteți verifica dacă fișierul aparține versiunii instalate. Dezactivarea validării semnăturii poate face o anumită aplicație utilizabilă, dar reduce protecția și ar trebui să fie o excepție documentată, nu o remediere de rutină.
Conectați-vă ca administrator și deschideți pagina Admin. Urmați avertismentul de integritate pentru lista de fișiere nevalide. În documentația ownCloud actuală, raportul grupează problemele după componentă, cum ar fi fișierele principale sau o aplicație, și utilizează etichete precum INVALID_HASH, FILE_MISSING, EXTRA_FILEși EXCEPTION. Aceste etichete indică cauze diferite, așadar înregistrați componenta, calea și eroarea înainte de a face modificări.
INVALID_HASHînseamnă că respectivul conținut al unui fișier nu corespunde cu hash-ul din datele sale de semnătură. Explicațiile frecvente includ o actualizare parțială, un fișier vechi lăsat la locul său sau o editare locală.FILE_MISSINGînseamnă că lipsește un fișier semnat. O extragere sau o implementare incompletă a arhivei poate cauza acest lucru.EXTRA_FILEînseamnă că instalarea conține un fișier care nu este listat în semnătură. Poate fi un fișier rămas accidental, un fișier personalizat sau o adăugare locală legitimă care necesită revizuire.EXCEPTIONînseamnă că ownCloud nu a putut verifica semnătura. Raportul poate indica faptul că lipsesc datele de semnătură, că certificatul este invalid sau revocat sau că verificarea nu s-a putut finaliza.Nu șterge un fișier doar pentru că apare ca fiind suplimentar. Confirmă ce face și cine l-a adăugat. În special, nu edita niciodată o aplicație signature.jsonpentru a dezactiva avertismentul; instrucțiunile de semnare a codului de la ownCloud spun explicit să nu îl modifici.
| Găsirea | Pasul următor preferat | Compromis |
|---|---|---|
| Mai multe fișiere de bază au hash-uri nevalide sau lipsesc după o actualizare manuală | Pregătiți o copie nouă a versiunii țintă exacte și restaurați fișierele oficiale afectate sau repetați actualizarea manuală fără probleme. | O actualizare curată necesită mai multă muncă și poate necesita timp de nefuncționare, dar reduce riscul de a lăsa un arbore de cod cu versiuni mixte. |
| Un fișier principal este invalid și știi că a fost editat local. | Comparați editarea cu fișierul de lansare corespunzător; păstrați modificarea personalizată în afara arborelui nucleu semnat și reaplicați-o numai dacă este acceptată. | Păstrarea modificării poate păstra comportamentul local, în timp ce editarea fișierelor de bază semnate va continua să eșueze verificările de integritate. |
| O aplicație raportează date de semnătură lipsă sau nevalide | Instalați o versiune compatibilă de la administratorul aplicației sau dezactivați/eliminați aplicația dacă nu mai este necesară. | O actualizare păstrează funcționalitatea; dezactivarea evită codul aplicației, dar poate elimina funcțiile de care depind utilizatorii. |
| Un certificat de aplicație este revocat sau nevalid | Solicitați administratorului aplicației o versiune compatibilă recent semnată; nu reutilizați și nu modificați fișierele de semnătură. | Acest lucru poate dura ceva timp, dar menține validarea semnăturii intactă. |
| Un fișier suplimentar este identificat | Verificați proprietarul, scopul și dacă face parte dintr-o personalizare înainte de a-l muta din directorul de instalare. | Eliminarea unui fișier necunoscut poate întrerupe o integrare locală sau poate șterge ceva important |
ownCloud 11 adaugă o considerație specifică versiunii: aplicațiile terțe trebuie să aibă semnături valide pentru a fi instalate, actualizate sau activate, iar o aplicație nevalidă poate fi blocată, nu doar semnalată. Începând cu 6 octombrie 2026, documentația ownCloud 11.0 precizează că aplicațiile care utilizează schema de semnare anterioară sunt acceptate cu un avertisment până la 31 decembrie 2026; după această dată, numai semnăturile din noul PKI sunt considerate de încredere. Dacă rulați ownCloud 10.x, consultați documentația pentru versiunea exactă în loc să presupuneți că se aplică regulile de aplicare 11.0.
Aceste precauții sunt importante deoarece un avertisment de integritate se referă la codul executabil al aplicației, în timp ce baza de date și fișierele utilizator sunt părți separate ale instalării. Restaurarea unui director de cod vechi peste fișiere mai noi gestionate de pachete poate crea neconcordanțe. Ghidul de actualizare ownCloud recomandă o copie de rezervă nouă, revizuirea notelor de lansare și a cerințelor și verificarea compatibilității aplicațiilor terțe înainte de o actualizare.
Dacă raportul numește căi oficiale pentru nucleu, cum ar fi index.php, version.php, sau fișiere sub arborele nucleu, obțineți arhiva oficială pentru versiunea exactă pe care doriți să o rulați în prezent. Nu utilizați o arhivă mai nouă doar pentru că este disponibilă: hash-urile de integritate corespund unei versiuni specifice.
Pentru o nepotrivire mică, bine înțeleasă, comparați calea raportată cu aceeași cale din arhiva respectivă. După ce confirmați că este un fișier oficial nemodificat, înlocuiți doar fișierul afectat, păstrând proprietatea și permisiunile necesare serverului web. Dacă lipsesc mai multe fișiere sau acestea nu corespund sau nu puteți determina ce versiune a furnizat fișierele live, o actualizare curată dintr-un director de lansare nouă este de obicei opțiunea mai fiabilă.
Pentru o instalare manuală a arhivei, modelul sigur este de a implementa versiunea separat, de a păstra configși data, apoi de a urma pașii oficiali de actualizare pentru mutarea codului la locul său. Nu suprascrieți directorul de date al utilizatorului cu conținutul arhivei. Implementările de pachete și containere au propriile proceduri de actualizare; utilizați-le în loc să aplicați metoda de arhivare manuală. Dacă transferați fișiere individuale cu FTP, documentația de integritate ownCloud specifică modul de transfer binar.
Dacă raportul denumește o aplicație în loc de versiunea principală, verificați mai întâi dacă aplicația respectivă este compatibilă cu versiunea dvs. ownCloud. Instalați o versiune oficială sau furnizată de către administrator care corespunde serverului și are o semnătură validă. Dacă nu există o versiune compatibilă, dezactivați aplicația și confirmați că acest lucru nu va întrerupe un flux de lucru necesar. Eliminarea unei aplicații este o opțiune mai permanentă și trebuie să urmeze instrucțiunile de eliminare ale aplicației.
Pentru ownCloud 11, dezactivarea validării pentru o anumită aplicație este o excepție controlată de administrator, care este înregistrată și pierde integritatea și protecția împotriva revocării pentru aplicația respectivă. Folosiți-o numai după evaluarea sursei și a impactului aplicației și documentați cine a aprobat excepția și de ce. Nu este o modalitate de a repara o instalare de bază coruptă sau modificată. Pentru versiunile mai vechi, comportamentul de aplicare disponibil diferă, așadar verificați documentația pentru versiunea instalată.
După corectarea fișierelor subiacente, utilizați acțiunea de rescanare a paginii Admin, dacă este disponibilă. De asemenea, puteți rula occverificările documentate. Pentru Docker Compose, ghidul actual de semnare a codului ownCloud oferă aceste exemple:
docker compose exec owncloud occ integrity:check-core
docker compose exec owncloud occ integrity:check-app calendarÎnlocuiți calendarcu ID-ul aplicației menționat în raport. Pentru instalările non-container, invocați occfișierul din directorul ownCloud ca utilizator al serverului web; calea și utilizatorul precise variază în funcție de sistemul de operare și de metoda de instalare. Comanda documentată verifică nucleul sau o aplicație denumită; ghidul actual spune că nu există o singură comandă acolo pentru rescanarea manuală a fiecărei aplicații.
O reparație este verificată atunci când un raport nou nu mai listează fișierele corectate și funcția relevantă funcționează normal. Dacă aceeași eroare hash reapare, căutați o implementare automată, un patch local, o lucrare de sincronizare sau un incident de securitate care modifică din nou fișierul. Dacă raportul indică un certificat revocat, o semnătură a aplicației lipsă sau o nepotrivire de versiune pe care nu o puteți rezolva dintr-o versiune oficială, opriți repetarea scanării și contactați administratorul aplicației sau asistența ownCloud cu raportul și versiunea exactă a serverului.
Alegeți un înlocuitor de fișier specific atunci când raportul identifică un fișier nucleu oficial, versiunea exactă este cunoscută și puteți găsi originalul corespunzător. Repetați actualizarea curată atunci când multe fișiere nucleu eșuează, actualizarea a fost întreruptă sau instalarea conține fișiere din mai multe versiuni. Pentru erorile care afectează doar aplicația, preferați o actualizare de către întreținător sau dezactivarea unei aplicații neutilizate; aceasta rezolvă componenta afectată fără a înlocui fișierele nucleu fără legătură. Rezervați excepții de validare pentru o aplicație specifică, evaluată, atunci când nu există un înlocuitor semnat și nevoia operațională depășește pierderea protecției integrității.
Pentru următoarea actualizare, consultați mai întâi notele de lansare și cerințele, dezactivați aplicațiile terțe incompatibile așa cum recomandă ownCloud și faceți o copie de rezervă nouă. Acești pași necesită timp de planificare, dar fac ca un avertisment de integritate post-actualizare să fie mai ușor de diagnosticat și recuperarea mai sigură.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
