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.
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 … … 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.
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…
How or by what? Where did you see this? What action were you performing then?