`~/.termux/termux.properties` doesn't work when it's a symlink.

[oneorseveralcats]

Trying to use nix to declaratively configure all aspects of termux and found out that ~/.termux/termux.properties can't be a symlink. There's an issue for it upstream, but they claim it'd be security issue to allow that file to be a symlink (termux/termux-app#4157).

I guess assuming that file can't be a symlink the next based thing would be using an activation script to deploy it?

Edit: I wrote an activation script. (termux.properties can be at either .termux/termux.properties on .config/termux/termux.properties)

build.activation.generateTermuxProperties = let
  path = "$HOME/.config/termux/termux.properties";
  settings = {
    fullscreen = true;
    use-fullscreen-workaround = true;
  };
in /* bash */ ''
  echo "generating termux.properties"
  $DRY_RUN_CMD mkdir -p $(dirname ${path})
  $DRY_RUN_CMD printf "# Generated by nix-on-droid. Warning: changes will be overwritten #\n" > "${path}"
  $DRY_RUN_CMD printf "${lib.generators.toKeyValue {} settings}" >> "${path}"
'';

[t184256]

wut. Alt idea: we maintain a fork of the app, you can file a PR to accept a symlink in the app. mind that it'll be a broken symlink you'd have to resolve with extra care. If you see how it's a security issue (I don't), you could check it's linking to n-o-d's /nix/store.

[oneorseveralcats]

i think if i saw symlinks as a security issue i'd stay very far away from nix. the security reason stated was because you could symlink it to public directories. there's also an option to allow external apps to run arbitrary commands using termux so that's probably the reason. i have no idea actually how much of a risk that actually is, but it seems very unlikely for that to

seems like a small reason to make a fork, do you have other reasons for wanting to? also, i don't immediately know how to make that change, but i can't imagine it's too difficult, so i'd be game lol.

edit: also, i think it'd probably make sense to have a n-o-d option for creating termux.properties (which is another contribution I can make).

[t184256]

On March 19, 2026 1:09:46 AM GMT+01:00, oneorseveralcats ***@***.***> wrote: oneorseveralcats left a comment (nix-community/nix-on-droid#512) i think if i saw symlinks as a security issue i'd stay very far away from nix. the security reason stated was because you could symlink it to public directories. there's also an option to allow external apps to run arbitrary commands using termux so that's probably the reason. i have no idea actually how much of a risk that actually is, but it seems very unlikely for that to seems like a small reason to make a fork, do you have other reasons for wanting to? also, i don't immediately know how to make that change, but i can't imagine it's too difficult, so i'd be game lol.

the fork in question, so you can see for yourself where we deviate: https://github.com/nix-community/nix-on-droid-app

[oneorseveralcats]

Been working on this issue but I'm a bit stumped. Got regular symlinks working relatively easily, but then, after that, /nix/store links wouldn't work. The termux FileUtils library wouldn't resolve the symlink and it took awhile to find the java approach/method to resolving broken symlinks (Files.readSymbolicLink).

After figuring that out, I appended /data/data/com.termux.nix/files/usr to the link (because i'm assuming that's where the nix directory actually resides [edit: it's actually just symlinks to /nix/store], and it still throws an error about the file being unreadable:

03-19 17:14:42.212 5236 5236 W Nix.TermuxSharedProperties: Ignoring properties file at "/data/data/com.termux.nix/files/usr/nix/store/ym27gsf2cnxyrcbhlypx1zqmfk3w4lpm-home-manager-files/.config/termux/termux.properties" since it is not readable

I'm kind of stumped.

Edit 2: I don't really know where the nix store would be accessible to termux when it's starting up because it doesn't appear able to access /nix/store.

[shelvacu]

You can see the full list of directory mappings here:

nix-on-droid/modules/environment/login/login.nix

Lines 49 to 59 in 55b6449

	exec ${installationDir}/bin/proot-static \
	-b ${installationDir}/nix:/nix \
	-b ${installationDir}/bin:/bin! \
	-b ${installationDir}/etc:/etc! \
	-b ${installationDir}/tmp:/tmp \
	-b ${installationDir}/usr:/usr \
	-b ${installationDir}/dev/shm:/dev/shm \
	$BIND_PROC_STAT \
	$BIND_PROC_UPTIME \
	-b /:/android \
	--link2symlink \

where installationDir is usually /data/data/com.termux.nix/files/usr, and there's also an implicit /:/ mapping, so any paths which don't match any of the above are mapped one-to-one, ex /data/foo in proot-land is /data/foo in android-land

So if the symlink points to /nix/store/foo..., trying to read /data/data/com.termux.nix/files/usr/nix/store/foo... should be the correct first step, but that might also be a symlink to an absolute path, which you'd need to manually resolve again...

However, if the file is a hardlink in proot-land, then it will be a symlink in android-land which again will need special code to resolve correctly.

I think it would make much more sense to say that symlinks aren't supported, and copies should be used instead. A warning from nix-on-droid-app would be helpful.

[oneorseveralcats]

Yeah, I'm pretty content with my activation script method. I've also been having issues with resolv.conf being garbage collected so I have an activation script that just generates that too.