Hi I would like my dietpi system to be readonly because is a kiosk and users can’t properly shutdown it
I found some similar topics here but nothing worked on my system, i have the latest version of dietpi
is there a simple options i missed? in raspberry pi os i usually set my system to readonly using raspi-config, but i cannot find the same option in dietpi-config.
Thanks for the help
Simply putting a system into r/o mode could break thinks. Therefore, some overlayFS might be needed. You could have a look into following if using a Raspberry Pi device Samba Fails on RO filesystem - #2 by Joulinar
But this is a couple of years old. Hopefully still working. At least a direction you can look into.
Thanks for the answer, i already tried that link but it did not work so since it was old i tought something changed in a few years.
i hoped there where an easy option but since it does not i will try those projects
thank you for your time
nope, theoretically you can set r/o mode in drive manager (I guess), but it will break some services who need r/w access. Therefore, some overlayFS is needed.
UNIX, which GNU/Linux is… extremely similar to by design, including the filesystem hierarchy standards, was from the start designed at least largely for what you seem to be requesting.
Back in the old days hard drives, tapes, etc would often have a physical switch or even a key (yes, similar type as to your home’s front door) with which the storage device would be physically disabled from writing to the media, leaving readonly mode.
This has been very helpful for example during the late 90s when “thin clients” were very popular amongst the UNIX-vendors (not the customers or their users) where the physical computer that the user would use would then generally only let the user write in /tmp but that by definition must be data that is presumed to be discarded at each reboot and therefore could be mounted in a RAM-filesystem to be auto-discarded at boot.
The /bin, /sbin, /lib, /usr/* /usr/local, /opt and so on were of course not for a user to write to, so defined as being required to be readonly-capable.
As for /var which by definition contains data to be written to (“variable” data → /var, the entire purpose of the directory and subdirectories, for end-users (e.g. corporate engineers designing cars, not computer engineers) their computers would normally only put log-files in there anyway and those could be saved on log-servers instead of locally, or only turned on when we came from the computers-department to look at some problem they had reported.
The system configuration should generally both in such large-scale cases and in what it sounds like in your case not occur on a whim at the device but only after careful consideration centrally (e.g. deploy new OS-image or push out via rsync or (depreciated) NFS).
The /home for a user that is not supposed to persistently change any configurations anyway could probably easily be made some tmpfs (auto-discarding at logout and/or reboot) with standardized config-files restored into the now otherwise empty home-directory by the system’s login-script.
All that said, a lot of experience and careful planning through the decades has recently been just kicked out because newcomers didn’t understand what it was or why, so it is entirely possible that your required software entirely ignores those excellent design standards.