Ensure proper handling of read-only filesystems #6

Open
opened 2023-03-08 14:55:50 +01:00 by basvandewiel · 3 comments
basvandewiel commented 2023-03-08 14:55:50 +01:00 (Migrated from github.com)

An NFS filesystem may be forced to read-only from the server's end. Check how MiSTer deals with that and adjust the script accordingly with mount options as needed. Maybe we should test for it and mount the filesystem read-only from our end as well to keep semantics straight between client and server.

  • Figure out if this is in fact an issue.
  • Design and implement a fix.
An NFS filesystem may be forced to read-only from the server's end. Check how MiSTer deals with that and adjust the script accordingly with mount options as needed. Maybe we should test for it and mount the filesystem read-only from our end as well to keep semantics straight between client and server. - Figure out if this is in fact an issue. - Design and implement a fix.
fooness commented 2023-03-08 15:44:57 +01:00 (Migrated from github.com)

What might be one or more reasons for mounting a network share with read-write permissions? I’m asking this maybe weird question because I’m not sure if we are able to perform any file system modification changes via the MiSTer FPGA interface?

I speculate that some reasons could be:

  • download and write content via update.sh or update_all.sh to network share
  • save and write states to network share

Well, or maybe it could be about write operations to the network share from the TTY of MiSTer FPGA system, either via direct keyboard input, or via ssh connection, for example?

What might be one or more reasons for mounting a network share with read-write permissions? I’m asking this maybe weird question because I’m not sure if we are able to perform any file system modification changes via the MiSTer FPGA interface? I speculate that some reasons could be: - download and write content via `update.sh` or `update_all.sh` to network share - save and write states to network share Well, or maybe it could be about write operations to the network share from the TTY of MiSTer FPGA system, either via direct keyboard input, or via `ssh` connection, for example?
basvandewiel commented 2023-03-09 16:05:45 +01:00 (Migrated from github.com)

On top of the reasons you already mention, I'd like the backing store for my hard drive images to be writable. I use the Amiga en AO486 cores extensively and they generally expect their hard disks to be read/write.

This may warrant a redesign in a later version that differentiates between arcade/console (mostly) and computers so we can differentiate this. I wouldn't want MiSTer to accidentally fudge up ROM's that don't need to be writable anyway but I do want my hard disks to be writable.

I'm going for the simplest use case first: assume a mount to be read/write and permit things to break on the MiSTer's end if that condition is false.

On top of the reasons you already mention, I'd like the backing store for my hard drive images to be writable. I use the Amiga en AO486 cores extensively and they generally expect their hard disks to be read/write. This may warrant a redesign in a later version that differentiates between arcade/console (mostly) and computers so we can differentiate this. I wouldn't want MiSTer to accidentally fudge up ROM's that don't need to be writable anyway but I do want my hard disks to be writable. I'm going for the simplest use case first: assume a mount to be read/write and permit things to break on the MiSTer's end if that condition is false.
basvandewiel commented 2023-03-09 16:39:50 +01:00 (Migrated from github.com)

Another potential tangle: remote file system permissions. MiSTer runs as root. NFS servers generally go full Gandalf on you and won't let you pass. Instead they kick you down to user 'nobody' on their end, which is fine but it will lead to files being read-only even if you're root and your mount itself is read-write. I feel some documentation needs coming up for this script. Either you change the permissions on your files and dirs appropriately or you add a maproot on your exports file to straighten the path for root.

Another potential tangle: remote file system permissions. MiSTer runs as root. NFS servers generally go full Gandalf on you and won't let you pass. Instead they kick you down to user 'nobody' on their end, which is fine but it will lead to files being read-only even if you're root and your mount itself is read-write. I feel some documentation needs coming up for this script. Either you change the permissions on your files and dirs appropriately or you add a maproot on your exports file to straighten the path for root.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Public/misternfs#6
No description provided.