fn
fn copied to clipboard
fnproject
upvote if you see read-only file system errors
in function logs there will be an error like:
msg="./my.sh: line 1: can't create file: Read-only file system\n"
if you'd like to 'fix' this temporarily, you may write to /tmp or disable this feature https://github.com/fnproject/fn/blob/master/docs/operating/options.md. we are smoke testing this and appreciate upvotes here if you run into issues so that we can track this, or any additional sentiments -- an upvote indicates you would like to write to anywhere in the container filesystem by default (i.e. as a user, your 'expectation') and/or this was challenging to work around (please provide details).
an upvote indicates you would like to write to anywhere in the container filesystem, as one might expect from a 'bring your own container' functions model.
talk about a push poll
we're walking a bit of a tight rope with OSS and service anyway, this restriction likely shouldn't last in OSS but we were curious the effects on users and this was the easiest way to generate data rather than sitting around talking hypotheticals
I think that the ability to wire an arbitrary container to run as a fn-function is a strong value proposition of the fn project. Essentially in this way you can web-enable an encapslulated legacy system and use it through HTTP without touching it. So I am upvoting.
Bumped into this yesterday prepping a demo*. It wasn't a massive deal (although the absence of a writable /run caught me out) - I could work around it; I can see the upsides of the change, but there are certainly cases where this'll cause surprise.
Dare I suggest this defaults to on but be tunable to "off"? (This introduces more moving parts, but in different circumstances I think I'd often appreciate having my function's fs inviolable.)
- the function container launched an internal service process that needed to read configuration from the fs - I was injecting that config via the app, and expected to be able to write it out.
one issue we have atm is that we aren't very upfront about this restriction, so it's more likely users run into it. there's something to be said for expectations, but we were mostly curious about cases where it's not possible or very challenging to work around this and if that's a practical reality or only hypothetical.
This doesn't talk about the benefits of protecting the root file system - I see this change as a massive benefit to users in terms of security, stability and performance .
It's good practice from a security perspective - at no point are any of the binaries or source files of your function writable directly, this protects against a large class of security vulnerabilities and is best practice in docker.
It improves the stability of systems running Fn - Before this change a single function could DOS the whole host it runs on by filling up the overlay top-layer file system. Whilst there are some ways of preventing functions from consuming too much space without removing write, (e.g. provisioning the top-layer in its own loopback FS,, using XFS Fs quotas) - both of these come with significant downsides either in performance and stability or they place additional restrictions on the type of machine that Fn runs (moving away from "it runs on any docker machine" as it does now).
Performance is considerably easier to control and the impacts of one container on another are easier to manage using this approach than sticking with Overlay - in Overlay - writing one byte to a 1GB file on the image causes 1GB of copy up , which in the case where we've had to up the top-layer into its own file system to prevent a single container from consuming a shared overlay FS, would be a cross-filesystem operation.
I am absolutely in favour of "the simplest experience possible" and i totally agree that this is not clearly documented - but I also think we are doing the best for our users here. - People want functions that work all the time as well as a simple experience.
The option to disable it is documented here: https://github.com/fnproject/fn/blob/master/docs/operating/options.md
there's a decent opportunity here to generate data on whether it should be enabled or disabled out of the box, which is the crux of the issue (or the intended one), though I certainly wish the original post for this issue looked more like https://github.com/fnproject/fn/issues/1113#issuecomment-403107554 to reference here.
if users are hitting this regularly and it's hard to work around, we have an interesting conversation around disabling it by default in OSS. we need some guide on 'battle hardened' config outside the scope of this configurable option existing & motivations therein, at least this wasn't the intent of that issue and maybe that should be clarified(?). there's a multiple-issue-spanning issue around consistent experience to be had between out-of-the-box installs vs. configured installs. I see 3 tiers: out-of-the-box install behavior, on-prem configured behavior and our service behavior, there's a whole spectrum to explore between complete freedom with OSS where everything works and there's no limits to mimicking the service exactly, we need some unity on that as we're not consistent at the moment (this is, at the moment, and perhaps should remain that way if the community doesn't give much feedback here) -- but maybe this is better done elsewhere since it's not #1113 directly.
feel free to edit the OP or close and [maybe] re-create. as the title suggests, it would be valuable feedback to know how many users run into the read only issue when running the OSS fn out of the box as well as providing them an outlet to provide feedback on this, and if we get that then we can analyze what to do from there for the out-of-the-box experience.
Just found this issue as a naive Fn user. Everything was working when I was using "fn run" locally and writing to the root filesystem, and then it all broke when I "fn deploy" deployed and called my function via http://path/to/function. The workaround is easy (write to /tmp). It is the fact that the behaviour is different when running via "fn run" and then running the function after "fn deploy".
I agree that most of the filesystem should be read-only. You need to be more upfront about this restriction, more consistent between functions run in different environment ("fn run" versus "fn deploy") and have more documentation steering users to develop functions that write to "/tmp" (or designate another area that should be read/write).
The documentation on how to fix this / disable it doesnt exist anymore?
Can anyone explain the fix to disable this?
