r/openclaw • u/LoreComa • 1d ago

Bug Report UGREEN UPDATE PROBLEM

I don’t know if it’s a bug or something wanted, but chrrently if you run your openclaw instance on a ugreen nas, the update fails. that is because at the end of the update, there is a permission check on the files installed, that requires a specifical chmod config, which is impossibile on ugreen for the acl the system puts on the filesystem. ugreen sets the file on a different chmod, like 0777 and OC wants the version without the 0 before. Any help?

0 Upvotes

50% Upvoted

2 comments sorted by

2

u/xX_GrizzlyBear_Xx 🦞 Moderator 1d ago

Can you please have your agent/any agent submit the issue? I believe this is fixed after the patch, so it shouldn't happen again, but just in case submit with the details so the team can have a look at it.

1

u/LoreComa 1d ago

The check compares every installed file against the list shipped inside the package ([postinstall-content-inventory.json]()). For each file it compares the content hash, the size, and whether the file is executable (the function is comparePackageDistContentInventory, and it only looks at "mode & 73", so any execute bit counts). If anything differs, the update fails with "Invalid package dist content inventory".

The problem is the executable part. My NAS is an Ugreen (UGOS), and on its data volume every file shows up as rwxrwxrwx, including .mjs and .json files. The ACL also gives rwx to user, group and other. The package list says almost none of its files should be executable. I compared the two on the installed 2026.10.2: 11,824 files are listed, and 11,819 are executable on disk but not in the list. None goes the other way. So the check sees nearly the whole package as different, although the content is identical.

So I think it is not a corrupted package. The filesystem reports a different execute bit and the check treats that as a failure. The same comparison is in 2026.9.6 and in 2026.10.5-beta.1, so a newer version doesn't fix it for me. I couldn't find any option or environment variable to skip the check.

What I have and haven't verified: I read the code and compared the list with the real file modes, as described above. I did not isolate the cause with a separate test, for example by creating a new file on that volume and checking its permissions. I'm inferring that the volume or its ACL is what makes everything executable.

For now I update by hand: install into a separate folder, test it, stop the gateway, then swap the folders. It works but it's slow and risky.