Image - how to exclude files from "root owned plus 644"

You don't need to read this post. It is based on outdated information.

As of Sep 2021, the make image process preserves the permissions of files included in the FILES= directory. Namely, the "644" portion of the problem no longer exists.*

*To be more accurate, the problem does not exist with the image builder downloaded from this page:

If you have a router for which development has stopped some time ago, you may be living in the past insofar as your router's image builder is concerned.

For the "root owned" portion of the problem, you may want to see this other post,

Image - an etc/uci-defaults script to chown

but only if you are a novice (like me) and don't know what a script must look like that is included in the /etc/uci-defaults directory.

What follows this line is based on outdated information.

According to these two sources

the image building process assigns to every included file root ownership plus 644 permissions.

If so, I will have a problem when I start wanting to include (in the image) directories and files that should not receive the "root ownership plus 644" treatment.

Examples would include sensitive files that should have more restrictive permissions (see linked sources for examples) and non-root user files that should not be root-owned (e.g. the non-root user home directory).

Question: How can I exclude designated directories and files from the "root owned plus 644" treatment?

Note that the linked sources refer to "modifying include/" as a solution. My problem with that would be that I don't even know what "include/" is. I would have to be told something like, "That's part of the XYZ process, which you need to understand. Start here," and the documentation.

Just a week or so ago, I did not know what "image building" was. I am not averse to learning any amount of materials so long as the sources are there and somebody can point them out to me. Thanks.


The idea that image building assigns to every included file the "644" permissions may be wrong.

I included these files in the make image process.

-rw-r--r--    1 root     root          1484 Aug  1 16:46 ssh_config
-rw-------    1 root     root           505 Sep  2 03:02 ssh_host_ecdsa_key
-rw-r--r--    1 root     root           174 Sep  2 03:02
-rw-------    1 root     root           399 Sep  2 02:29 ssh_host_ed25519_key
-rw-r--r--    1 root     root            94 Sep  2 02:29
-rw-------    1 root     root          2602 Sep  2 02:29 ssh_host_rsa_key
-rw-r--r--    1 root     root           566 Sep  2 02:29
-rw-r--r--    1 root     root          3115 Aug  1 16:46 sshd_config

At the time of inclusion in the image building, they had to be non-root owned (per requirement of the process), but with the permissions you see above.

On flashing, their counters in the router had the various 644 and 600 permissions (as above). Namely, permissions were preserved as we have already been told here:

Can I run `image make` even if some files are root-owned? - #8 by vgaetera

Maybe the behavior of make image has changed since the time of the two links at the top of this post.

I'll do further tests. If permission are preserved, only the "root owned" portion of the problem would remain.


I ran more tests. Put files of various permissions into make image, flashed the router, and got following results (from the router), which show that permissions are preserved.

root@OpenWrt:/etc/dump# ls -l
-r--r--r--    1 root     root             0 Sep  2 14:09 file444
-rw-------    1 root     root             0 Sep  2 14:08 file600
-rw-r-----    1 root     root             0 Sep  2 14:09 file640
-rw-r--r--    1 root     root             0 Sep  2 14:08 file644
-rw-rw----    1 root     root             0 Sep  2 14:09 file660
-rw-rw-rw-    1 root     root             0 Sep  2 14:08 file666
-rwx------    1 root     root             0 Sep  2 14:08 file700
-rwxr--r--    1 root     root             0 Sep  2 14:08 file744
-rwxrw----    1 root     root             0 Sep  2 14:09 file760
-rwxrw-r--    1 root     root             0 Sep  2 14:08 file764
-rwxrw-rw-    1 root     root             0 Sep  2 14:08 file766
-rwxrwxrwx    1 root     root             0 Sep  2 14:07 file777

Sorry about the original portion of the post, which contained (what must be) outdated information.

I think the "root owned" portion of the problem (without "644") will be far more manageable; maybe with a /etc/uci-defaults script.

Can we hear some more about your use case?

Can you please tell us more about;

  • the files / paths
  • users / groups involved and account creation method/s
  • permissions required
  • current errors

Sure. One use case is the creation of a non-root user. I follow this OldWiki:

I believe it gives all the info on expected ownership and permissions, including e.g. the fact that a user (not root) should own its own home directory.

The second use case is installing OpenSSH to replace Dropbear. I follow these sources:

They are not exactly the same. I had to mix and match.

A third case would be ksmbd. I'm afraid there was not a whole lot on this, but I summarize my steps here:

Set up ksmbd for read and write access as named user

I don't have any current errors. I expect that files will be "root owned plus 644" which should be otherwise; that, if you'd like, would be the error.

P.S. A fourth use case may be Wireguard. It is a future project for me (have not looked too much into it yet). But presumably there will be key pairs, for which the "44" portion of "644" may not be appropriate?

1 Like

Create a Makefile and use the appropriate install method.;a=blob;;h=8b24d3a3bb416e4f39365052d9f9136e716caf9f;hb=HEAD#l282

1 Like

New URL:

The old page is for archival purposes only and does not receive updates any more.


1 Like

You were absolutely right to ask them. Tests show that "644" was not an issue. Permissions are preserved. See ADDENDUM 2. Another lesson learned: Always check things yourself. Thanks again.