This warning appears when dpkg cannot fully delete a directory during package removal or upgrade because the directory still contains files. This is usually harmless and occurs when package maintainers add new files that older versions didn't account for. The directory can typically be manually cleaned up or left as-is since it doesn't prevent the package operation from completing.
When dpkg removes or upgrades a package, it attempts to delete directories that were part of the old package structure. If the directory contains leftover files (especially newer files added in recent package versions), dpkg cannot delete the non-empty directory and emits this warning. This typically happens with system directories like /etc, /usr/lib, or /var that contain configuration files or plugins beyond what dpkg owns. The warning indicates that while the package files were removed successfully, some directory cleanup couldn't be completed.
This warning is generally not a problem and does not prevent your package operation from completing. dpkg has already removed the package files successfully; it simply couldn't delete the directory because it's not empty. The warning is informational rather than critical. You can safely continue using your system and the package.
If you want to investigate what's left in the directory, use ls to view its contents. Replace /path with the actual directory from the warning message:
ls -la /pathThis will show you what files or subdirectories are still present. If the directory is empty but the warning still occurred, the issue may have already resolved itself.
If you're removing a package and want to ensure all configuration files and related directories are cleaned up, use purge instead of remove:
sudo apt purge package-namePurge removes both the package and all associated configuration files. Use apt purge after apt remove on packages you're no longer using:
sudo apt remove package-name
sudo apt purge package-nameThis is more thorough than remove alone but may still not delete directories if they contain other non-owned files.
If you've verified that the leftover directory contains only orphaned files and nothing important, you can manually remove it. First, verify the directory is safe to delete by checking its contents:
sudo ls -la /pathIf the directory is empty or contains only files you don't need:
sudo rmdir /pathFor directories with contents, use:
sudo rm -rf /pathBe extremely careful with rm -rf as it irreversibly deletes files. Only use this on directories you fully understand and can verify are safe to remove.
Run the apt cleaning commands to remove unused dependencies and temporary files:
sudo apt autoremove
sudo apt autocleanapt autoremove removes packages that were automatically installed but are no longer needed by any installed package. apt autoclean clears the apt package cache of old package files. These won't directly fix directory cleanup but help maintain a clean system.
List all packages that have been removed but not purged (marked as "rc" in dpkg):
dpkg --list | grep '~rc'To purge all remaining unpurged packages at once:
sudo apt purge ~cOr purge specific unpurged packages:
sudo apt purge package-nameThis removes configuration files and may clean up orphaned directories that weren't handled during the initial removal.
This warning is a known long-standing dpkg behavior documented in Debian bug reports. It occurs because dpkg uses a "declaim ownership" modelโit can only delete directories it explicitly owns in the package manifest. When package maintainers modify the structure across versions, directories that were tracked in old packages may contain new files added by newer versions, causing the cleanup to fail. Distribution transitions (like /usr-merge on modern Debian systems) can also trigger these warnings across many packages. System administrators may find it acceptable to leave these directories in place, as they don't interfere with system operation. For production systems, the conservative approach is to document which directories have this warning and only remove them after verification that no running services depend on them. Some package managers (like apt with full-text search) maintain package file ownership databases in /var/lib/dpkg/info/ which can help identify what package "owns" a file. Containers and clean system installations won't see these warnings, as they start fresh without legacy package modifications. On systems that use SELinux or AppArmor, leaving unexpected files in system directories might trigger security warnings, though dpkg itself doesn't enforce this.
E: Cannot set to hold: package 'package-name' is not installed
How to fix "Cannot set to hold" error when package is not installed in APT
debconf: unable to initialize frontend: Dialog
How to fix "debconf: unable to initialize frontend: Dialog" in APT
E: Could not connect to proxy server
Could not connect to proxy server
dpkg: serious warning: files list file for package 'package-name' contains empty filename
How to fix "files list file contains empty filename" in APT
E: Package 'package:i386' has no installation candidate
How to fix "Package package:i386 has no installation candidate" in apt