0444 problem

Hi All,
I found a critical bug (for me) with new OSMC version based on Kodi 17.
After “clean install” new versions of OSMC on my Raspberry Pi 2, I get into the “terminal” and I blocked some files in OSMC directores before accidental overwriting or unintended change. In previous versions of OSMC if I use the command “chmod 444” on for example guisettings.xml file it didn’t produce anything negative in OSMC but in new OSMC version based on Kodi 17, OSMC crashes on startup.

Please fix this problem or help me, because I use “chmod 444” to create a “fool-proof” my own OSMC.

Start a new post with logs.

Where are the logs?

However I don’t understand that use command “chmod 444 guisettings.xml” on older versions works perfectly but on the new version (Krypton) it crashes and OSMC can’t start (reboot all the time)

Check https://osmc.tv/wiki/general/how-to-submit-a-useful-support-request

444 is RO
It’s possible you set this after Kodi made any necessary changes and before the major update.
If you allow RW temporarily then set RO after, you’ll probably be fine

But Kodi isn’t really designed to allow this and this isn’t an OSMC or Kodi issue. If you’re that concerned about your guisettings, take a backup

Closing unless you can demonstrate unnecessary writes to the file

Thank you for reply.

Temporarily set RW and then set RO not works, in short: OSMC (Krypton) starts only if guisettings.xml file owner has write access (chmod 644 for example). Previous versions of OSMC (Kodi 16, Kodi 15) didn’t have this problem (I use chmod 444 [Read only] on this file in older OSMC versions and it works perfectly) - Yes, I know that maybe Kodi isn’t designed to do this, but I don’t know why this “fool-proof blockade” works in older versions and crashes in this new (Kodi 17) version. This is very strange.

PS: I have a little question not related to the main topic - Can I disable a “system total up time” counter?

We believe this is a Kodi issue or a specific Kodi function and as such you should look at addressing the issue there. We are unable to resolve your issue. If you do believe that this is an OSMC specific issue, please let us know.

guisettings is meant to be written to

There is no good reason why you cannot simply backup this file and keep this backup.
Unless you can provide a compelling reason I cannot see why this is an important issue for us to fix. Corruption is extremely rare and not catastrophic.

I use “chmod 444 guisettings.xml” for two reasons.

First to prevent accidental setting changes. (I have backup this file too, but that is not the point)
Second to reset “system total uptime”, so that every time OSMC start, counter showing a zero - It maybe stupidity for someone but it is important for me (and not just for me - I found on the internet that many users were using this method to reset counter through the blockade (command chmod 444))

Uptime is not passed to any source.

There’s no reason to keep uptime at 0 unless you are reselling OSMC :wink:
If you are, you should follow our reseller guide.

Keep uptime at 0 is important to me.

Anyway, could you say what you mean (‘reseller guide’)?

Why?

If I didn’t know any better, I’d think you were reselling OSMC, making some customisations and trying to keep the uptime at 0 before selling it. That would be a violation of our trademark policy, and gives you additional responsibilities under the GPL.

Don’t do it.

Can you provide a compelling reason to keep uptime at 0?

The reason is simple because I like it when in every OSMC start the uptime counter starts from zero. Different things people like and I like it.

Using chmod command to block the guisettings.xml file did the two important (for me) things:
First (as I said) - Uptime counter starts from zero in every time when I turn on my Raspberry Pi 2 (with OSMC)

Second (as I said eariler) - In order to prevent accidental changing of settings.

In earlier versions of OSMC you can do it and it works perfectly, so in newer versions I should be able to do the same.

I don’t like when some things in newer versions cease to function (like some kind of regress)

If someone has a solution of this problem please reply or send to the developers Kodi information about this issue in new Kodi Krypton. (Can’t do the read only file - guisettings.xml)

Kodi Krypton now writes to the guisettings file periodically. The idea is to avoid potential corruption or loss of settings that would occur when trying to write everything out at once.

I’ve seen a couple of potential issues with it however, so it may be adjusted or reverted in the future.

I think some Kodi skins show system uptime and total Kodi uptime.

This topic was automatically closed after 3 days. New replies are no longer allowed.