Uninstall Urbackup and now can not delete folder/files

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | cat /boot/dietpi/.version
dietpi@DietPi:/$  cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=10
G_DIETPI_VERSION_SUB=7
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
dietpi@DietPi:/$
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
dietpi@DietPi:/$ echo $G_DISTRO_NAME $G_RASPBIAN
trixie
  • Kernel version | uname --all
dietpi@DietPi:/$ uname --all
Linux DietPi 6.18.45-current-rockchip64 #1 SMP PREEMPT Wed Aug 19 16:18:21 UTC 2026 aarch64 GNU/Linux
dietpi@DietPi:/$
  • Architecture | dpkg --print-architecture
dietpi@DietPi:/$ dpkg --print-architecture
arm64
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
dietpi@DietPi:/$ echo $G_HW_MODEL_NAME or (EG: RPi3)
-bash: syntax error near unexpected token `('
dietpi@DietPi:/$
  • Power supply used | (EG: 5V 1A RAVpower)
  • SD card used | (EG: SanDisk ultra)

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. Uninstall Urbackup and you are left with some undeleteable files and directories.
  2. …

Expected behaviour

  • Able as sudo to delete a folder or files.

Actual behaviour

  • …

Extra details

  • …
paste lines of logs or code into such code fences here

Here is the folder in question after the uninstall.

dietpi@DietPi:/$ ll mnt/dietpi_userdata/
total 0
drwxrwxr-x 1 dietpi dietpi 532 Sep 22 14:58 downloads
drwxr-xr-x 1 dietpi dietpi  28 Jan 27  2024 filebrowser
drwxrwxr-x 1 dietpi dietpi   0 May  3 11:12 Music
drwx------ 1 dietpi dietpi 136 Dec 20  2024 syncthing
drwxr-xr-x 1    109    114  66 Jul  6 14:35 urbackup
drwxrwxr-x 1 dietpi dietpi   0 May  3 11:12 Video
dietpi@DietPi:/$

Here is what is inside the file,

dietpi@DietPi:/$ ll -a mnt/dietpi_userdata/urbackup
total 0
drwxr-xr-x 1    109    114  66 Jul  6 14:35 .
drwxrwxr-x 1 dietpi dietpi 116 Sep 22 14:59 ..
drwxr-x--- 1    109    114 388 May 26 21:22 HPLee
drwxr-x--- 1    109    114 344 Apr 26 03:26 minusforum
drwxr-x--- 1    109    114   0 May 26 21:22 urbackup_tmp_files
dietpi@DietPi:/$

I can not delete any of these files or folders even as sudo???

dietpi@DietPi:/$ rm -rf mnt/dietpi_userdata/urbackup/
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee': Permission denied
rm: cannot remove 'mnt/dietpi_userdata/urbackup/minusforum': Permission denied
rm: cannot remove 'mnt/dietpi_userdata/urbackup/urbackup_tmp_files': Permission denied
dietpi@DietPi:/$ rm -rf mnt/dietpi_userdata/urbackup/HPLee/
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee/': Permission denied

I forgot the sudo output, it goes on like that for a long time.

dietpi@DietPi:/$ sudo rm -rf  mnt/dietpi_userdata/urbackup/
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.dir_metadata': Read-only file system
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.cache/.dir_metadata': Read-only file system
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.urbackup_snaps/.dir_metadata': Read-only file system
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/bin': Read-only file system
rm: cannot remove 'mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/boot/.

I feel I must be doing something really dumb but can’t figure out what.

This is also probably related but again, too stupid today apparently.

Seems related.

3

Did you config to use BTRFS snapshots for urbackup to use?
Can you check

findmnt -R /mnt/dietpi_userdata/urbackup
findmnt -T /mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.dir_metadata
df -T /mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.dir_metadata
grep -i urbackup /proc/self/mountinfo
4

is this a NFS mount?

df -h
5

Updated: I was in love wth BTRFS snapshots for a while and it is possible that I had tried that feature of Urbackup.

Not really sure, i got some feedback from your commands but still not sure.

dietpi@DietPi:~$ findmnt -T /mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.dir_metadata
dietpi@DietPi:~$ sudo findmnt -T /mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.dir_metadata
TARGET   SOURCE    FSTYPE OPTIONS
/mnt/sda systemd-1 autofs rw,relatime,fd=61,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2462
/mnt/sda /dev/sda1 btrfs  rw,noatime,lazytime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/
dietpi@DietPi:~$ sudo findmnt -R /mnt/dietpi_userdata/urbackup
dietpi@DietPi:~$ sudo df -T /mnt/dietpi_userdata/urbackup/HPLee/251022-1010/.hashes/rootfs/.dir_metadata
Filesystem     Type 1K-blocks      Used Available Use% Mounted on
-              -    976760832 212971852 761782420  22% /mnt/sda/dietpi_userdata/urbackup/HPLee/251022-1010
dietpi@DietPi:~$ grep -i urbackup /proc/self/mountinfo
dietpi@DietPi:~$ sudo grep -i urbackup /proc/self/mountinfo
dietpi@DietPi:~$
6 
dietpi@DietPi:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           386M  9.5M  376M   3% /run
/dev/mmcblk2p1  114G  4.1G  105G   4% /
tmpfs           1.9G  3.4M  1.9G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs            50M   16K   50M   1% /var/log
tmpfs           1.9G     0  1.9G   0% /tmp
/dev/sda1       932G  204G  727G  22% /mnt/sda
tmpfs           1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
/dev/sdb1       932G  216G  702G  24% /mnt/sdb
tmpfs           386M  4.0K  386M   1% /run/user/1000
7

Right now the whole dietpiuserdata is exported via Samba and I am working all this from a Mac and ssh.

8

So /mnt/sda with the userdata in it is a Btrfs. But there seem to be submounts, missed by the commands as /mnt/dietpi_userdata is a symlink to /mnt/sda/dietpi_userdata. Let’s check again:

sudo findmnt -R /mnt/sda
9 
dietpi@DietPi:~$ sudo findmnt -R /mnt/sda
TARGET     SOURCE    FSTYPE OPTIONS
/mnt/sda   systemd-1 autofs rw,relatime,fd=61,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2462
└─/mnt/sda /dev/sda1 btrfs  rw,noatime,lazytime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/
dietpi@DietPi:~$
10

can you also check

sudo btrfs subvolume list /mnt/sda
11

and to check if the sub volume is r/o

sudo btrfs property get -ts /mnt/sda/dietpi_userdata/urbackup/HPLee/251022-1010 ro
12 
dietpi@DietPi:~$ sudo btrfs subvolume list /mnt/sda
ID 639 gen 7637 top level 5 path dietpi_userdata/urbackup/minusforum/250621-0952
ID 716 gen 8594 top level 5 path dietpi_userdata/urbackup/minusforum/250806-1525
ID 723 gen 8806 top level 5 path dietpi_userdata/urbackup/minusforum/251020-1349
ID 729 gen 8923 top level 5 path dietpi_userdata/urbackup/HPLee/251022-1010
ID 779 gen 9453 top level 5 path dietpi_userdata/urbackup/HPLee/251228-1101
ID 814 gen 9711 top level 5 path dietpi_userdata/urbackup/HPLee/260219-1403
ID 888 gen 10297 top level 5 path dietpi_userdata/urbackup/minusforum/260322-1503
ID 900 gen 10230 top level 5 path dietpi_userdata/urbackup/HPLee/260327-1055
ID 949 gen 10484 top level 5 path dietpi_userdata/urbackup/minusforum/260413-1320
ID 950 gen 10506 top level 5 path dietpi_userdata/urbackup/minusforum/260413-1823
ID 953 gen 10513 top level 5 path dietpi_userdata/urbackup/minusforum/260414-0920
ID 954 gen 10522 top level 5 path dietpi_userdata/urbackup/minusforum/260414-1422
ID 955 gen 10561 top level 5 path dietpi_userdata/urbackup/minusforum/260414-2012
ID 958 gen 10583 top level 5 path dietpi_userdata/urbackup/HPLee/260415-1657
ID 963 gen 10566 top level 5 path dietpi_userdata/urbackup/minusforum/260417-1407
ID 968 gen 10732 top level 5 path dietpi_userdata/urbackup/HPLee/260419-1919
ID 977 gen 10719 top level 5 path dietpi_userdata/urbackup/minusforum/260423-1047
ID 978 gen 10752 top level 5 path dietpi_userdata/urbackup/minusforum/260423-1549
ID 979 gen 10738 top level 5 path dietpi_userdata/urbackup/HPLee/260423-1944
ID 982 gen 10778 top level 5 path dietpi_userdata/urbackup/minusforum/260424-1156
ID 985 gen 10787 top level 5 path dietpi_userdata/urbackup/minusforum/260425-1222
ID 986 gen 10792 top level 5 path dietpi_userdata/urbackup/minusforum/260425-1723
ID 989 gen 10908 top level 5 path dietpi_userdata/urbackup/HPLee/260426-1950
ID 996 gen 10924 top level 5 path dietpi_userdata/urbackup/HPLee/260429-1908
ID 999 gen 10993 top level 5 path dietpi_userdata/urbackup/HPLee/260430-1750
ID 1002 gen 11041 top level 5 path dietpi_userdata/urbackup/HPLee/260513-2028
ID 1007 gen 11066 top level 5 path dietpi_userdata/urbackup/HPLee/260522-2037
ID 1012 gen 11073 top level 5 path dietpi_userdata/urbackup/HPLee/260524-1024
ID 1013 gen 11092 top level 5 path dietpi_userdata/urbackup/HPLee/260524-1528
ID 1016 gen 11097 top level 5 path dietpi_userdata/urbackup/HPLee/260525-2056
ID 1019 gen 11114 top level 5 path dietpi_userdata/urbackup/HPLee/260526-2007
ID 1020 gen 11205 top level 5 path dietpi_userdata/urbackup/HPLee/260526-2033
dietpi@DietPi:~$ 


dietpi@DietPi:~$ sudo btrfs property get -ts /mnt/sda/dietpi_userdata/urbackup/HPLee/251022-1010 ro
ro=true
dietpi@DietPi:~$

Looks like read only???

13 
dietpi@DietPi:~$ sudo btrfs property get -ts /mnt/sda/dietpi_userdata/urbackup/HPLee/251022-1010 ro
ro=true
dietpi@DietPi:~$

Looks Like Read only???

14

Side note: I used Claude.ai to generate the commands and step-by-step instructions.Claude is an AI and can make mistakes. :wink:

Thanks for the output, that confirms it. Every UrBackup backup was created as its own Btrfs snapshot (subvolume), and ro=true means these snapshots are read-only. That’s why rm -rf fails even as root with “Read-only file system”. rm is simply the wrong tool here, Btrfs subvolumes need to be removed with btrfs subvolume delete. Deleting the subvolume itself works even if it’s read-only, since the flag only protects its contents.

Good news: all subvolumes sit directly at top level 5, so there are no nested subvolumes and the order of deletion doesn’t matter.

Before you start: if you still need anything from these backups, copy it somewhere else first. Deleting subvolumes is permanent.

  1. List all affected subvolumes (dry run, nothing gets deleted):
sudo btrfs subvolume list /mnt/sda | awk '$NF ~ /^dietpi_userdata\/urbackup\//{print "/mnt/sda/"$NF}'
  1. Test with a single snapshot first:
sudo btrfs subvolume delete /mnt/sda/dietpi_userdata/urbackup/HPLee/251022-1010
  1. If that worked, delete all remaining ones in one go:
sudo btrfs subvolume list /mnt/sda | awk '$NF ~ /^dietpi_userdata\/urbackup\//{print "/mnt/sda/"$NF}' | xargs -r sudo btrfs subvolume delete
  1. Wait until Btrfs has actually freed the space in the background:
sudo btrfs subvolume sync /mnt/sda
  1. Remove the leftovers (now just regular directories like urbackup_tmp_files):
sudo rm -rf /mnt/sda/dietpi_userdata/urbackup
  1. Verify that nothing is left and the space was freed:
sudo btrfs subvolume list /mnt/sda

df -h /mnt/sda

In case step 2 still fails with “Read-only file system” or “Operation not permitted”, clear the read-only flag first. For a single snapshot:

sudo btrfs property set -ts /mnt/sda/dietpi_userdata/urbackup/HPLee/251022-1010 ro false

Or for all of them at once:

sudo btrfs subvolume list /mnt/sda | awk '$NF ~ /^dietpi_userdata\/urbackup\//{print "/mnt/sda/"$NF}' | xargs -r -I{} sudo btrfs property set -ts {} ro false

Then continue with step 3.

15

Wow it worked, thank you so much. I did not have to do the extra steps everything worked, steps one through six did the trick.

Thank you guys for figuring this out, not really a dietpi problem after all really so thanks for the help. Maybe this helps someone else as well.

16

Yes it’s the nature of the BTRFS snapshots, they are always read-only as far as I know.

I guess to circumvent this problem you would need to delete the snapshots before you remove UrBackup.

17

As UrBackup seems to make use of Btrfs snapshots automatically, looks like we should add this to uninstall steps, if /mnt/dietpi_userdata/urbackup is located on a Btrfs, with a yes/no dialog prior to remove everything?

18

Yes that probably would be helpful to some, otherwise I guess it would be there forever.

19

Done in dietpi-software: UrBackup: offer to delete Btrfs snapshots on uninstall by Joulinar · Pull Request #8348 · MichaIng/DietPi · GitHub :slightly_smiling_face:.