Is snap making my filesystem read only?

so ive been setting up my main desktop with manjaro for the past day or so, and ive been running into an issue where everything in the root filesystem gets marked as read only. the only exception so far is my external 2tb drive, but i still need the files on all my other drives.

i think i narrowed it down to one main issue. snap. i know its not recommended to install snap on arch based distros, but im using a program called sosumi that is only available via snap. not even a direct download.

the more i look into my own issue the weirder it gets. on my desktop is where the problems lie, thats where im using manjaro kde. but on my laptop, i decided to give gnome a try. i did the same setup over there and everything is virtually identical. only difference is that the file system isnt read only. back over on my desktop, im also having the issue of steam not being able to pick up any of my drives now that theyre read only (again, the one exception being my external 2tb). i know snap isnt the best option, and sosumi isnt even recommended by most, but its all that ive actually been able to get working right now. is there any fix for the issue?

ps, the package managers still work and can install and uninstall things just fine, and i have already tried uninstalling snap just to see if that would work.

Some system info would be nice - especially the information oabout your root partition’s filesystem

inxi -Fc0

If the filesystem is btrfs it may go readonly if errors are deteted - doing so to prevent further damage to the filesystem.

System:
  Host: clevland-steambox Kernel: 6.1.38-1-MANJARO arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.6 Distro: Manjaro Linux
Machine:
  Type: Desktop System: Gigabyte product: A320M-S2H v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: A320M-S2H-CF serial: <superuser required>
    UEFI: American Megatrends LLC. v: F55 date: 06/07/2022
CPU:
  Info: 6-core model: AMD Ryzen 5 5600X bits: 64 type: MT MCP cache: L2: 3 MiB
  Speed (MHz): avg: 2197 min/max: 2200/4650 cores: 1: 2196 2: 2199 3: 2198
    4: 2200 5: 2200 6: 2203 7: 2200 8: 2198 9: 2200 10: 2188 11: 2187 12: 2199
Graphics:
  Device-1: NVIDIA TU116 [GeForce GTX 1660 Ti] driver: nouveau v: kernel
  Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.2 driver: X:
    loaded: modesetting dri: nouveau gpu: nouveau resolution: 1: 1920x1080~60Hz
    2: 1440x900~60Hz
  API: OpenGL v: 4.3 Mesa 23.0.4 renderer: NV168
Audio:
  Device-1: NVIDIA TU116 High Definition Audio driver: snd_hda_intel
  Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel
  Device-3: Turtle Beach driver: hid-generic,snd-usb-audio,usbhid type: USB
  API: ALSA v: k6.1.38-1-MANJARO status: kernel-api
  Server-1: PulseAudio v: 16.1 status: active
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
  IF: enp11s0 state: down mac: b4:2e:99:cb:ca:80
  IF-ID-1: wlp14s0f3u3 state: up mac: 44:01:bb:97:6d:9c
Bluetooth:
  Device-1: Broadcom BCM20702A0 Bluetooth 4.0 driver: btusb type: USB
  Report: rfkill ID: hci0 state: up address: see --recommends
Drives:
  Local Storage: total: 3.76 TiB used: 2.72 TiB (72.4%)
  ID-1: /dev/nvme0n1 vendor: Western Digital model: WDS500G2B0C-00PXH0
    size: 465.76 GiB
  ID-2: /dev/sda vendor: Western Digital model: WDS100T2B0A-00SM50
    size: 931.51 GiB
  ID-3: /dev/sdb vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB
  ID-4: /dev/sdc vendor: Samsung model: MZNLF128HCHP-000L1 size: 119.24 GiB
  ID-5: /dev/sdd vendor: Seagate model: BUP Slim size: 1.82 TiB type: USB
Partition:
  ID-1: / size: 107.86 GiB used: 11.69 GiB (10.8%) fs: ext4 dev: /dev/sdc2
  ID-2: /boot/efi size: 299.4 MiB used: 288 KiB (0.1%) fs: vfat
    dev: /dev/sdc1
Swap:
  ID-1: swap-1 type: partition size: 8.8 GiB used: 0 KiB (0.0%) dev: /dev/sdc3
Sensors:
  System Temperatures: cpu: 53.4 C mobo: N/A gpu: nouveau temp: 32.0 C
  Fan Speeds (RPM): N/A gpu: nouveau fan: 779
Info:
  Processes: 318 Uptime: 55m Memory: total: 16 GiB available: 15.54 GiB
  used: 4.72 GiB (30.4%) Shell: Zsh inxi: 3.3.28

i dont believe it is btrfs. this is a fresh install from today, and i generally tend to default to ext4

I see from your inxi that the filesystem is ext4.

In my opinion - a good choice - it also tells me you are no novice.

As you are no novice - you are of course aware that the entire root filesystem - with the tine execption of your home is supposed to be read only.

Is the filesystem on the device hosting your steam games - an ntfs formatted device?

If so - one could suspect you are dual booting Windows and that Windows has not been shut down completely - but is using hibernate or Windows fast startup.

i may have knowledge, but ive still made enough mistakes to be a novice and it definitely shows here.

im not so sure read only is the best terminology here. in dolphin, all my system folders explicitly prevent my from creating, deleting, or modifying files of any kind. normally id assume this is typical manjaro behavior, but again i have a laptop that ive been dualbooting as well and havent run into this issue there. i can create, delete, and modify anything in the root directory as long as im in sudo. on my kde desktop however, any attempt at modification (even when logged into root) yields errors.

kate brings up the following

The document could not be saved, as it was not possible to write to /etc/environment.
Check that you have write access to this file or that enough disk space is available.
The original file may be lost or damaged. Don't quit the application until the file is successfully written.

and nano bluntly states that the filesystem is read only.

i could see this maybe being the case, but to my knowledge that should only affect the windows c drive. i have about 4 drives including c that are internal, and all of them are read only. this is including the one thats exclusively used for linux and isnt touched by windows. on top of that, fastboot and hibernation were never enabled (unfortunatley my motherboard is old enough that it came with fastboot disabled at first), and windows is set to just turn off the display and keep the rest of the system running. in the four years ive had it, it hasnt slept once, and i instead opt to fully shut things down.

it also somewhat contradicts how i successfully set up the same drives earlier today when things were working. i had an original install from this morning with steam set up before trying sosumi, and it detected all my drives (including my c drive) and all the games on them, and proceeded to update them. i did a fresh install of steam after sosumi and snap (new install of manjaro too) and thats when it stopped detecting my games and drives.

I see … :confused: … I was just pulling up some ideas as to why it could be.

Manjaro behaves like every other systemd based Linux - there is no differences there …

If you cannot edit a file - not even using root - there is somehting weird going on …

The above is expected behavior

This behavior however is not

As for the topic title - Is snap making my filesystem read only? - no - I don’t think so - not on it’s own at least.

But as snap is sandboxing apps, it requires apparmor and while I know it exist, I have never taken turns with apparmor and to that extend no experince at all, but one speculates if an apparmor rule/profile is blocking access to the filesystem.

AppArmor proactively protects the operating system and applications from external or internal threats and even zero-day attacks by enforcing a specific rule set on a per application basis. Security policies completely define what system resources individual applications can access, and with what privileges. Access is denied by default if no profile says otherwise. A few default policies are included with AppArmor and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.
– AppArmor - ArchWiki

Although that may not be necessary - I suggest you boot on the live USB - then run fsck for your devices - to verify the filesystem.

No, this is a typical behaviour for Linux. Just install from AUR kde-servicemenu-rootactions and then if you want to modify something, right click it and choose “admin action”, unless those are config files, which you can open in kwrite or kate, edit and save it after putting your root password.

You can, of course, do that actions in terminal or install mc (terminal file manager app) as a friendlier version.

However, you shouldn’t be tinkering with root files too much or at all. The more you change them, the bigger the risk that you mess something. Just do backups frequently. Basically, if you change something in root, you have to know what you are doing, why, what it is going to do.

P.S. Snap are not making root read only. Snaps are not in the root. There is no relation here.

I use snaps and do have apparmor installed, but have no apparmor rules, so basically apparmor does nothing, but snaps work fine, so I’m not sure if apparmor is really required for snaps.

@Vantablack, Manjaro or even Arch is not the safest distro (many packages come with vanilla settings and are not configured with high security in mind), but that is not its goal, and for average user purposes, it’s fine. However, if you want something secure, you need to educate yourself and modify the system accordingly.

fastboot in BIOS is not the same as Windows fast startup (hybrid hibernation)

Disable or Enable Windows 10 Fast Startup (and Why) | Sysnative Forums
Dual boot with Windows - ArchWiki

1 Like

apparmor does appear to be installed, but after having uninstalled snaps and sosumi and performing a quick reboot (not exactly quick, did work for a day and used win for a bit when i got home), the files do appear to be writeable now.

im well aware of this. my main reason for chosing manjaro is the fact that its something i already have experience in, its been easier for me personally to use than ubuntu or pop, and its parallels with steamOS have made getting back into it much easier.

i initially intended to dualboot my system when i built it, and the only reason i didnt was because i had some random issues with splitting drive partitions. im more able to do it now that i have an extra drive that wasnt being used for anything. but those settings were manually disabled from the get go, and windows update hasnt appeared to have changed any of that.

tl;dr, no real solution yet (sorry people with the same issue looking for a fix), but uninstalling snap and restarting my system does appear to work as a temporary fix for now.

Obviously there is some misunderstanding here. We thought, you meant that the files are not writable by the user and that is a normal state. However, it seems you are talking about something else. Hmm…

You said:

How or by what? Where did you see this? What action were you performing then?