Ustaw publiczny adres URL NextCloud, aby mógł się do siebie dodzwonić
Napraw ostrzeżenie Nextcloud o brakującym adresie wychodzącym, ustawiając jego kanoniczny adres URL i sprawdzając routing DNS, HTTPS i odwrotnego serwera proxy na samym serwerze.
Jeśli APT zgłasza błąd „Nie można zweryfikować następujących podpisów”, zidentyfikuj repozytorium i konkretny kod błędu w tym samym wyniku, a następnie napraw zaufany klucz podpisu lub wpis źródłowy tego repozytorium. W przypadku repozytorium innej firmy uzyskaj jego aktualny klucz od wydawcy oprogramowania i powiąż go ze źródłem za pomocą Signed-By; nie wyłączaj sprawdzania podpisów ani nie dodawaj nieznanego klucza globalnie.

Uruchom aktualizację, aby sprawdzić pełną wiadomość:
sudo apt update
Poszukaj adresu URL obok Err:i tokena, takiego jak NO_PUBKEY, EXPKEYSIG, KEYEXPIREDlub BADSIG. Adres URL wskazuje, które źródło nie powiodło się; token zawęża przyczynę. APT weryfikuje podpisane metadane repozytorium przed zatwierdzeniem indeksu pakietu, więc niepowodzenie weryfikacji podpisu jest sygnałem bezpieczeństwa, a nie powierzchownym ostrzeżeniem. Instalacje Ubuntu zawierają już klucze do domyślnych archiwów Ubuntu; ręczna konfiguracja kluczy jest zazwyczaj wymagana tylko w przypadku repozytoriów dodanych później.
Znajdź definicję źródła, wyszukując hosta o nazwie podanej w błędzie. Zastąp przykładowy host tym z terminala:

grep -R "packages.example.org" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
Ubuntu 24.04 i nowsze używają plików źródłowych deb822 z .sourcesdomyślnie zakończonym rozszerzeniem; starsze instalacje często mają pliki jednowierszowe .list. Sprawdź adres URL repozytorium, nazwę kodową pakietu lub Ubuntu oraz wszelkie istniejące Signed-Bywpisy. Jeśli kod źródłowy wskazuje na wersję, której dostawca już nie wspiera, skorzystaj z instrukcji dostawcy dla swojej wersji Ubuntu lub wyłącz ten kod źródłowy. Klucz nie może naprawić przestarzałej lub nieprawidłowej ścieżki do repozytorium.
W przypadku NO_PUBKEY, najpierw upewnij się, że repozytorium zostało celowo zainstalowane. Otwórz aktualną dokumentację instalacyjną wydawcy i uzyskaj adres URL klucza podpisu oraz pełny odcisk palca z tego źródła. Porównaj odcisk palca z oddzielnie opublikowanym odnośnikiem do dostawcy, jeśli jest dostępny. Nie pobieraj klucza z losowego serwera kluczy tylko dlatego, że jego krótki identyfikator pasuje do błędu.
W przypadku dostawcy publikującego .ascklucz z zabezpieczeniem ASCII zainstaluj go jako dedykowany pęk kluczy APT. Zastąp przykładowy adres URL dokładnym adresem URL udokumentowanym przez tego wydawcę:
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://vendor.example/path/repo-signing-key.asc | sudo gpg --dearmor --yes -o /etc/apt/keyrings/vendor-archive.gpg
sudo chmod 0644 /etc/apt/keyrings/vendor-archive.gpg
Plik .gpgmusi być czytelny dla nieuprawnionego użytkownika pobierającego APT. Jeśli wydawca udostępnia binarny .gpgpęk kluczy, należy postępować zgodnie z jego instrukcjami, zamiast ponownie go aktualizować. Ubuntu zaleca, aby klucze stron trzecich znajdowały się w oddzielnym pęku kluczy i były odwoływane przez to repozytorium, ograniczając w ten sposób możliwość korzystania z klucza przez poszczególne źródła.

Edytuj istniejącą definicję źródła zamiast dodawać duplikat. W przypadku pliku deb822, takiego jak /etc/apt/sources.list.d/vendor.sources, użyj rzeczywistych wartości URI, pakietu i komponentu dostawcy, a następnie dodaj ścieżkę do pęku kluczy:
Types: deb
URIs: https://packages.example.org/ubuntu
Suites: YOUR_UBUNTU_CODENAME
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive.gpg
Jeśli istniejący wpis znajduje się w pliku jednowierszowym .list, równoważna składnia to deb [signed-by=/etc/apt/keyrings/vendor-archive.gpg] https://packages.example.org/ubuntu YOUR_UBUNTU_CODENAME main. Zachowaj udokumentowany pakiet i komponenty repozytorium; przykładowe wartości są symbolami zastępczymi. Unikaj apt-key add: jest przestarzały, a globalny klucz zaufany może przyznać kluczowi zewnętrznemu szersze uprawnienia niż zamierzone.
Jeśli komunikat brzmi EXPKEYSIG„lub” KEYEXPIRED, klucz podpisu mógł wygasnąć lub dostawca mógł go wymienić. Pobierz i zweryfikuj klucz zastępczy zgodnie z aktualnymi instrukcjami dostawcy, a następnie zaktualizuj pęk kluczy źródłowych. Nie przedłużaj okresu zaufania starego klucza, ignorując datę wygaśnięcia.
Jeśli repozytorium jest oficjalnym archiwum Ubuntu, nie importuj klucza innej firmy. Sprawdź, czy zegar systemowy jest poprawny za pomocą timedatectl status, i potwierdź, że źródło używa prawidłowego adresu URL archiwum Ubuntu oraz nazwy kodowej zainstalowanej wersji. ubuntu-keyringPakiet zawiera klucze podpisywania archiwum Ubuntu; jeśli zarządzanie pakietami nadal działa za pośrednictwem zaufanego źródła Ubuntu, odśwież ten pakiet za pomocą:
sudo apt install --reinstall ubuntu-keyring
Komunikat BADSIGoznacza, że podpis nie zgadza się z metadanymi otrzymanymi przez APT. Ponowne importowanie klucza zazwyczaj jest błędną odpowiedzią. Sprawdź, czy zegar systemowy jest nieprawidłowy, czy nie występuje nieaktualne lub niespójne lustro, serwer proxy buforujący lub problem z publikacją po stronie repozytorium; spróbuj ponownie po usunięciu przyczyny. Jeśli tylko źródło zewnętrzne zawodzi i nie jest potrzebne, wyłącz jego specyfikację .sourceslub .listwpis, kontaktując się z jego administratorem. Pozostaw włączoną weryfikację bezpieczeństwa.

Uruchom sudo apt updateponownie. Naprawa zostanie zakończona, gdy repozytorium zostanie pobrane bez ostrzeżenia o podpisie, a APT osiągnie Reading package lists... Done. Pomyślna aktualizacja nie potwierdza bezpieczeństwa zewnętrznego wydawcy; potwierdza jedynie, że podpis metadanych jest zgodny z kluczem, któremu ufasz. Jeśli weryfikacja nadal się nie powiedzie, przed wprowadzeniem kolejnej zmiany sprawdź ponownie adres URL repozytorium, nazwę kodową, odcisk klucza, uprawnienia do pęku kluczy i dokładny token błędu.
Aby zapoznać się z obsługiwanymi formatami źródeł i kluczy, zapoznaj się z poradnikiem Ubuntu dotyczącym repozytoriów stron trzecich , podręcznikiem Ubuntu apt-secure i dokumentacją integralności archiwum Ubuntu .
Napraw ostrzeżenie Nextcloud o brakującym adresie wychodzącym, ustawiając jego kanoniczny adres URL i sprawdzając routing DNS, HTTPS i odwrotnego serwera proxy na samym serwerze.
Skonfiguruj APCu i Redis przez lokalne gniazdo Unix na potrzeby buforowania i blokowania plików w usłudze Nextcloud, wraz z instrukcjami dla bieżących i starszych wersji usługi Nextcloud.
Sprawdź tryb cron Nextcloud, napraw usługę systemd i timer oraz zweryfikuj, czy zadania w tle są uruchamiane po uruchomieniu i co pięć minut.
Włącz niezawodne blokowanie plików Nextcloud, wybierz odpowiedni serwer Redis lub Valkey i sprawdź, czy ostrzeżenie zostanie usunięte bez ryzyka równoczesnych zmian w plikach.
Napraw typowe błędy skanowania Nextcloud dzięki bieżącym aktualizacjom, protokołom HTTPS i HSTS, precyzyjnemu zaufaniu do odwrotnego serwera proxy i sprawdzeniu względem serwera publicznego.
Skonfiguruj Nextcloud SSE dla pamięci masowej, która tego wymaga, chroń klucze szyfrujące i zmierz wpływ transferu i procesora przed zaszyfrowaniem istniejących plików.
Połącz wyszukiwarkę plików Nextcloud z Elasticsearch, zindeksuj zawartość dokumentów i wybierz konfigurację odpowiadającą Twoim potrzebom w zakresie serwera i bezpieczeństwa.
Skonfiguruj Nextcloud tak, aby usuwał usunięte pliki po upływie określonego czasu przechowywania, niezawodnie planował zadania w tle i unikał poleceń, które usuwają śmieci każdego użytkownika.
Wykonaj bezpieczną naprawę OCC w Nextcloud, przejrzyj zmiany w bazie danych i sprawdź, dlaczego ostrzeżenie może nadal się pojawiać.
Zezwól na przesyłanie większych plików przez przeglądarkę Nextcloud, dostosowując ustawienia PHP, Nginx lub Apache, tymczasowego miejsca przechowywania i limitu czasu — i sprawdź, który limit blokuje plik.