I don’t know when this happened. There was a system update a few days ago which went fine. Two days ago I wanted to download something onto one of my HDDs and got an I/O error. After investigating I found out that I no longer am the owner of any of my drives and can’t create/delete any files. Chmod/chown didn’t help. Editing the fstab file didn’t help since it had the exact same contens as when everything worked. Shuffeling exec,rw around has no effect. Mounting/unmounting didn’t do anything. Phisically removing the drives also didn’t work. Adding a completely new drive automatically set it to restricted. How the hell does soemthing like this happen? I don’t want to do a system wipe.
Edit: Windows is to blame
It appears Windows did something to the drives the last time I used it which messed up the partitin tables and prevented Linux from mounting them correctly. After poking around in the journalctl like suggested I found an entry with the error message. Googling brought me to an arch forum post with the same problem. All that had to be done was to go back into Windows and run shutdown /s /f /t 0 in cmd/powershell.
Link to the post: https://bbs.archlinux.org/viewtopic.php?id=231375
Tnx everyone for the assistance!
I am not familiar with I/O stuff, but I didn’t see you mention if you tried doing an
rpm-ostree rollback.Since you said it happened after an update, did you already try that to see if it fixes your issue? Another thing to look at is
topgrade.It’s the underlying tool for Bazzite upgrades, so perhaps that can give you some clues as to what went wrong.ETA: Have you tried asking in their discord? The community and devs are really nice and generally pretty helpful.
Tnx for the suggestions. I have asked on the discord server, but no response as of now. I will take a look at those commands and see if anything fixes it.
Filesystems may be remounted read only on error. I’d expect that to be reverted post reboot, but maybe your error was big enough for it not to? You may want to search how to perform an fsck on the affected partitions.
I touhgt the same, but connecting a new drive and getting the same “read-only file system” error is really strange. I used the other drive for qbittorrent and it worked flawlessly before the update. I haven’t come around to try any of the suggestions yet. I’ll report back tonight.
Did you disable fastboot in windows to make sure this doesn’t happen again?
Fastboot was never enabled to begin with :-/
It might also be worth ruling out low-level issues:
- Check for anything strange in the BIOS related to disks (fwupdmgr can automatically install BIOS updates from a live Linux session. I don’t know if Bazzite does this)
- Try using a different SATA port
- Run some SMART tests on your drives
Bazzite uses
topgrade, which I think also callsfwupdmgr.I’ll check the BIOS stuff tonight.
As for the sata port, the new drive was connected to a different one so it can’t be it. I did a drive health check and all seemed well and good.
Boot from a livecd and figure out what is going on.
Where would I start? Any commands I should try or just see if the livecd let’s me take control?
Just a shot in the dark:
Backup your fstab, then edit it to mount the drives to a subdirectory of your home.
Maybe that’ll get you back access.I’ll give ut a shot first before the other suggestions. Tnx
Can you restore a backup image? Sometimes that’s easier to roll back a day rather than spend all the time trying to troubleshoot.
I think bazzite uses systemd.
You can use journalctl to see the logs and find out what happened. They’re pretty straightforward to understand.
E: journalctl, not systemctl.
*journalctl
Jfc yes thank you.
Ok, I foxed it! I looked around in the log of which I mostly understood nothing, but then I came acress the section where the kernel/shstemd mounts the drives and the error it spits out. Googling it gave me an arch forum post with the identical problem. Windows didn’t shutdown correvtly the last time I used it and did something to the partition table. I’ll update my post wiy the solution.
Hell yeah
Tnx. I will report back tonight when I get around checking.
Is anything going down in the system log when you mount a drive, or trigger an access error? If it’s (one of the many) security systems clamping down, they tend to log that.
Can you read/write to the disks as root? If so, then something has likely gone sideways with your fstab entry. For example, the device name, order, or UID/GID may have changed, depending on how you’ve configured the entry.
It’s difficult to assist much more without seeing the contents of
/etc/fstab.I checked fstab and it’s the same from day one. I tired adding stuff to it and shuffeling parameters around (like phtting rw,exec last), but it did nothing.
Your fstab file can remain unchanged and still fail, if the drive or user identifiers have changed unexpectedly. It depends on how you’ve configured your fstab entries, which is why it’s helpful to share them. In future, no one will be able to offer much assistance without seeing the entry details. Either way, glad you were able to get it sorted!
