boot volume is almost full, after jail back up

[goatnas]

During 1st backup of emby media server, I received the below message. The back up hung the computer, so I had to shut it down. I am still receiving the following error:
CRITICAL: The capacity for the volume "freenas-boot" is currently at 95%, while the recommended value is below 80%.

I had it with trying to figure out emby updates, may try plex. I attempted reinstalling Free-Nas TWICE because of errors with emby. The system would not boot into install screens when I originally tried to install v11.2 earlier this year.

I'm not computer savvy, so this stumped me easily. Is learning how to mirror a bad thing to look into now? I mean, the boot drive doesn't have a back up.
I'm also unsure if I should chuck my computer versus guessing if buying an i5 / i7 will improve things.

Code:

# zpool status -v          all pools are healthy
# du -sh /root/             15K    /root/     
# zpool status -v freenas-boot                           
  pool: freenas-boot                                                           
 state: ONLINE                                                                 
  scan: scrub repaired 0 in 0 days 00:21:19 with 0 errors on Tue Oct 29 14:39:54
 2019                                                                           
config:                                                                         
                                                                                
        NAME        STATE     READ WRITE CKSUM                                 
        freenas-boot  ONLINE       0     0     0                               
          da1p2     ONLINE       0     0     0                                 
                                                                                
errors: No known data errors

Code:

# zfs list -r -o space,refer,written -t all freenas-boot
NAME                                           AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD  REFER  WRITTEN
freenas-boot                                    393M  28.4G         0     64K              0      28.4G    64K      64K
freenas-boot/ROOT                               393M  28.4G         0     29K              0      28.4G    29K      29K
freenas-boot/ROOT/Initial-Install               393M     1K         0      1K              0          0   740M       1K
freenas-boot/ROOT/Wizard-2019-08-01_08:50:05    393M     1K         0      1K              0          0   740M       1K
freenas-boot/ROOT/default                       393M  28.4G     4.17M   28.4G              0          0  28.4G    27.7G
freenas-boot/ROOT/default@2019-08-01-15:16:08      -  2.31M         -       -              -          -   740M     740M
freenas-boot/ROOT/default@2019-08-01-11:50:05      -   614K         -       -              -          -   740M    2.35M
freenas-boot/grub                               393M  7.11M         0   7.11M              0          0  7.11M    7.11M

Code:

# zfs get space freenas-boot                             
NAME          PROPERTY              VALUE          SOURCE                       
freenas-boot  name                  freenas-boot   -                           
freenas-boot  available             394M           -                           
freenas-boot  used                  28.4G          -                           
freenas-boot  usedbysnapshots       0              -                           
freenas-boot  usedbydataset         64K            -                           
freenas-boot  usedbyrefreservation  0              -                           
freenas-boot  usedbychildren        28.4G          -           

Some info from: smartctl -a /dev/ada0
Firmware Version: HP40
User Capacity: 750,156,374,016 bytes [750 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Thu Oct 31 18:19:16 2019 EDT

8Gb ram , sandy bridge Pentium

 

[dlavigne]

What are your System -> System Dataset settings?

 

[goatnas]

forgot to say that I'm using 11.1
System -> System Dataset settings
System dataset pool: ada0
Syslog: (unselected)
Reporting Database: (unselected)

 

[dlavigne]

IIRC, that was an issue in the 11.1 series. Are you able to perform a backup/upgrade window to 11.2-U6?

 

[sretalla]

What is your backup target? if it's not in your data pool (should be /mnt/...), it will be going to a child of root (/) and hence the boot pool.

I guess you already thought about that, but it's worth a check.

 

[goatnas]

I think I might have to cave and buy a processor, so I can upgrade to 11.3 . I was hoping to keep with the original one, since the computer was barely used.

But, thank you everyone for your input. Sretalla was right, most of the forum posts I was was referencing for the backups pointed to /usr/... , instead of the /mnt. I didn't think that it would try to backup the actual movie files. I managed to find my notes where I wrote down the pathway where the backup was saved. I wish I knew how I can clean up the rest of the files, but this looks solved. These are the results from the deletion:

Code:

]# rm -rf embyserver1                                                       
rm: embyserver1/embyserverbk.bak/lib/libthr.so.3: Operation not permitted       
rm: embyserver1/embyserverbk.bak/lib/libc.so.7: Operation not permitted         
rm: embyserver1/embyserverbk.bak/lib/libcrypt.so.5: Operation not permitted     
rm: embyserver1/embyserverbk.bak/lib: Directory not empty                       
rm: embyserver1/embyserverbk.bak/sbin/init: Operation not permitted             
rm: embyserver1/embyserverbk.bak/sbin: Directory not empty                     
rm: embyserver1/embyserverbk.bak/libexec/ld-elf.so.1: Operation not permitted   
rm: embyserver1/embyserverbk.bak/libexec/ld-elf32.so.1: Operation not permitted
rm: embyserver1/embyserverbk.bak/libexec: Directory not empty                   
rm: embyserver1/embyserverbk.bak/var/empty: Operation not permitted             
rm: embyserver1/embyserverbk.bak/var: Directory not empty                       
rm: embyserver1/embyserverbk.bak: Directory not empty                           
rm: embyserver1: Directory not empty  

Code:

# zfs list -r -o space,refer,written -t all freenas-boot
NAME                                           AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD  REFER  WRITTEN
freenas-boot                                   28.1G   754M         0     64K              0       754M    64K      64K
freenas-boot/ROOT                              28.1G   746M         0     29K              0       746M    29K      29K
freenas-boot/ROOT/Initial-Install              28.1G     1K         0      1K              0          0   740M       1K
freenas-boot/ROOT/Wizard-2019-08-01_08:50:05   28.1G     1K         0      1K              0          0   740M       1K
freenas-boot/ROOT/default                      28.1G   746M     4.17M    741M              0          0   741M    3.27M
freenas-boot/ROOT/default@2019-08-01-15:16:08      -  2.31M         -       -              -          -   740M     740M
freenas-boot/ROOT/default@2019-08-01-11:50:05      -   614K         -       -              -          -   740M    2.35M
freenas-boot/grub                              28.1G  7.12M         0   7.12M              0          0  7.12M    7.12M

Thank you

 

[sretalla]

It looks like you managed to eliminate the items that were taking all the space (28G now free).

I can't see the path you're in when trying to rm the remaining contents, but the files referenced are possible symbolic links in a typical jail structure pointing out to the files on the host, so I guess there's some trouble there, which then follows when the directories containing those can't be deleted either as they aren't empty.

You might want to look at trying just to rm one single file (like embyserver1/embyserverbk.bak/lib/libthr.so.3) and see if you can do it with sudo or at least ll (that's shorthand in unix for ls -l, I recently discovered) to see the permissions... perhaps there are inhibit delete permissions, so you could correct that with chmod 777 perhaps?