Questions[squashfs](ubuntu)

I have an Ubuntu 20.04 server installed on a single 8GB drive. The default installation has some "snap"s installed also. So, there are some "squashfs" file systems also reported by the df command:

# df -mT
Filesystem     Type     1M-blocks  Used Available Use% Mounted on
/dev/root      ext4          7877  1837      6025  24% /
devtmpfs       devtmpfs       465     0       465   0% /dev
tmpfs          tmpfs          477     0       477   0% /dev/shm
tmpfs          tmpfs           96     1        95   1% /run
tmpfs          tmpfs            5     0         5   0% /run/lock
tmpfs          tmpfs          477     0       477   0% /sys/fs/cgroup
/dev/loop0     squashfs        18    18         0 100% /snap/amazon-ssm-agent/1566
/dev/loop1     squashfs        94    94         0 100% /snap/core/9066
/dev/loop2     squashfs        55    55         0 100% /snap/core18/1705
/dev/loop3     squashfs        69    69         0 100% /snap/lxd/14804
/dev/loop4     squashfs        70    70         0 100% /snap/lxd/14890
/dev/loop5     squashfs        55    55         0 100% /snap/core18/1754
tmpfs          tmpfs           96     0        96   0% /run/user/1000

As you see, there is only 1837MB of data stored in the (only) disk.

Now, I am trying the list that disk usage for each directory present under root (/) using the following command:

# du -smc /* 2>/dev/null
0   /bin
48  /boot
0   /dev
8   /etc
1   /home
0   /lib
0   /lib32
0   /lib64
0   /libx32
1   /lost+found
1   /media
1   /mnt
1   /opt
0   /proc
1   /root
1   /run
0   /sbin
1116    /snap
1   /srv
0   /sys
1   /tmp
1166    /usr
601 /var
2938    total

The output shows a large amount of disk space used by the /snap directory, which of course is not true.

What is the correct way to count the size of files residing only on "real disk" filesystems? Adding the option -x to du does not make me feel comfortable, because in the future I may have another "real disk" filesystem mounted under /home for example and I do want that to be counted in du's output.

I am having real troubles sorting this out!

Why is the blkid output flooded with so many instances of /dev/loopx: TYPE="squashfs"?

No significant information is available on the internet!

Any help would be really appreciated.

Abbas.

I have installed Ubuntu for my dad instead of Windows recently and he really wanted an alternative to his favourite file manager Total Commander, so I went with Krusader which I myself have been using for ages.

However in Ubuntu 18.04 there seem to be a functionality called snaps in place which supposedly generates some loop partitions based on squashfs that get listed in Krusader's media list and by doing so are cluttering up that media list and are giving my dad a headache.

I have found out that one should be able to just remove snaps functionality:

Small snap loop devices visible in gnome-disk-utility OR what is the function of snap ubuntu-core

Why are all snaps being mounted and listed as block devices or partitions for Ubuntu 18.04?

How can I disable snaps in gnome-software centre?

How do I hide the loop partitions in Nautilus created by Snap app?

but to be honest I am a little afraid that I can delete something that will cause the system to be buggy. I would rather have an option in Krusader not to show any squashfs partitions. They are not being displayed in Disks or Nautilus and it would be great if I could set it up like that in Krusader too. I did look in preferences but cannot find anything relating to it.

So, is there a way to hide them in Krusader?

EDIT: here is the picture. It would not let me take a screenshot when the list is opened for some reason so I took a pic with my phone :/

I have installed a package using snap and I need to modify one of the files but when I try to change its ownership or permissions, I always get the following message:

sudo chmod +x ./my_file.js
chmod: changing permissions of '/snap/my_app/my_file.js': Read-only file system

How can I modify files that are installed via snap?

Was interested to know why, with space/bandwidth at such a premium, is full compression not used during squash.

For example, calling mksquashfs with the -comp xz -b 1M options at compression time creates an archive which weighs in at about 80% of the original filesystem.squashfs; yet appears to retain full integrity as both an installation and live image.

Does anybody have some intel here?