Cannot delete .mozilla directory

Hello,

I have a strange problem in being unable to delete parts of the .mozilla directory on a machine I maintain. Most of it is gone but some remains:

Code:
 rm -rf .mozilla/
 rm: .mozilla/firefox/7e1p93ma.default/storage/default/https+++www.youtube.com/cache/morgue/244: Directory not empty
 rm: .mozilla/firefox/7e1p93ma.default/storage/default/https+++www.youtube.com/cache/morgue/222: Directory not empty
I have tried chflags -R noschg without success. Neither directory has any content and when (in desperation) I run rm -rf * in either, the machine reboots.

I have tried running fsck(8) on the offending partition in case the file system is corrupted but nothing changed.

I appreciate any help and suggestions on how to fix this.

Sprock
 
I have tried running fsck(8) on the offending partition in case the file system is corrupted but nothing changed.
Run fsck(8) in single user mode, it cannot fix certain filesystem issues if the filesystem is mounted read/write. And, perhaps stating the obvious, it only works on UFS filesystems, it won't work on ZFS.
 
What version of FreeBSD is this? There have been some changes to fsck(8) recently to fix certain edge cases.

Neither directory has any content and when (in desperation) I run rm -rf * in either, the machine reboots.
That shouldn't happen. But it's probably a good indication the filesytem is corrupted in a really bad way. Was this an immediate reboot or did a panic(9) occur?

Did you check the drive itself with smartctl(8)? It might have some bad blocks that caused the corruption.
 
also try to run fsck -f so the journal is not used
also out of curiosity
if you run rm -frv * where it reboots
you can take a video with your smartphone
or if you cd to where you ran rm -fr * and type
find .
or echo *
what is the output ?
 
[…] I run rm -rf * in either […]
The command is usually rm -Rf * .* since * alone will not expand to dot files. Nonetheless, it’s unlikely there are any dot files since .mozilla is already a hidden directory (i. e. redundant: “hiding hidden stuff”).​
Apropos, you know, I find asterisks in conjunction rm(1) a bit scary. Perhaps for the next time, the find(1) solution is:​
Bash:
find .mozilla -print -delete # -print can be omitted
The strange thing is that the original rm -rf .mozilla/ did (and [still?] does) apparently not cause an immediate reboot. The behavior of rm(1) should not depend on your working directory. If nothing else helps, I suggest “surgical” removal: Mount the disk from a different system (maybe a Linux machine) and rm(1) it from there.​
 
Are files being created in those directories while you are concurrently trying to delete them? ie, are you running firefox while it is still creating files in the directories you are attempting to delete? This would cause the same error.
 
Try as root ?
Unlikely. That filetree should be maintained by firefox, which runs as the user.

In such a case, I usually stop trying to achieve what I originally wanted to achieve (delete that tree), and at first try to analyze what is actually going on. Here two things are going on that should not happen: recursive rm should get rid of the filetree, and it should not reboot the machine.

So in this case I would first get the machine into a consolidated state: none of the concerned processes running (or single-user), and then I would look into these directories, what is actually in there, causing problems. If it is an inconsistency in the inode table, then usually a mere ls -a will show no issues, but ls -la will show some strange message.

These directories seem to contain files with ugly filenames containing braces, so if perchance the rm is aliased to something else,that may yield interesting effects...
 
If `rm -rf *` does anything else than saying "no such file or directory", including a reboot, then there must be directory entries there.

No unlink(2) system calls would be issued if the dir is empty.
 
With the command specified, rm -rf .mozilla it is expected that it removes absolutely everything including said directory. That error though, seems fishy. And chance you are using some sort of alias on rm itself ? alias rm is one way of finding out..
 
Hello,

Thanks to all who answered.

1. smartctl showed up nothing:
Code:
 smartctl --test long /dev/ada0
smartctl 7.4 2023-08-01 r5530 [FreeBSD 12.4-RELEASE-p6 amd64] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 39 minutes for test to complete.
Test will complete after Wed Nov  1 22:23:05 2023 NDT
Use smartctl -X to abort test.

I waited 8 hours.

2. fsck -f showed up some problems:
Code:
** /dev/ada0p2 (NO WRITE)

SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
DIRECTORY CORRUPTED  I=20230352  OWNER=cmason MODE=40755
SIZE=1024 MTIME=Sep 26 13:29 2023
DIR=/usr/home/cmason/.mozilla/firefox/7e1p93ma.default/storage/default/https+++www.youtube.com/cache/morgue/244

UNEXPECTED SOFT UPDATE INCONSISTENCY

SALVAGE? no

DIRECTORY CORRUPTED  I=20305207  OWNER=cmason MODE=40755
SIZE=1024 MTIME=Sep 26 13:29 2023
DIR=/usr/home/cmason/.mozilla/firefox/7e1p93ma.default/storage/default/https+++www.youtube.com/cache/morgue/222

UNEXPECTED SOFT UPDATE INCONSISTENCY
SALVAGE? no

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE  I=3267483  OWNER=root MODE=140666 SIZE=0 MTIME=Jul 12
** 17:35 2023
RECONNECT? no
CLEAR? no

UNREF FILE  I=3267503
OWNER=root MODE=140600 SIZE=0 MTIME=Jul 12 17:35 2023
RECONNECT? no
CLEAR? no

UNREF FILE  I=3267523  OWNER=root MODE=100600 SIZE=3 MTIME=Jul 12
17:35 2023
RECONNECT? no
CLEAR? no

UNREF FILE  I=3852289
OWNER=root
MODE=100600
SIZE=0
MTIME=Jun 28 06:51 2023
RECONNECT? no
CLEAR? no

...

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

Before I try anything else, how do I fix the filesystem?

Thanks,
Roger
 
When you first encountered the issue, did you check syslog for additional messages ?

I have tried running fsck(8) on the offending partition in case the file system is corrupted but nothing changed.
How did you run the fsck ? Was the FS mounted, did you run it with -y, etc. It's important to know if you maybe didn't make it worse with this fsck run.
Inconsistent FS state could be due to the reboot (possible panic), i.e. it's not the root cause of the initial issue.

If you don't have dump available system does reboot to handle panic by default. You could again check the syslog to see additional messages that would give us better picture of the situation. covacat's suggestion to make a video would also provide that information (we'd be looking for a short message before actual reboot).

If you have data on that partition that is important and you don't have backup of I advise you not to be trigger happy with the fsck -y just yet. My 2c.
 
Tried fsck -y with the FS mounted read-only: still cannot delete .mozilla.
Tried fsck -y with the FS not mounted: same.

Other ideas?

Thanks,
Roger
 
Back
Top