Group Name not shown in --long listings in exa 0.9.0 (OpenBSD 6.7)

[jeffrollin]

When using the long listing format (--long or -l) with the --group or -g option, the group identifiers displayed are the numeric GIDs, not the group names. The user names display as expected. The issue is the same whether running exa as a regular user or as root. /etc/group permissions, and group and user details in /etc/group and /etc/passwd, have been checked and are correct.

[Freaky]

Likely an issue with https://github.com/ogham/rust-users

Relevant code: https://github.com/ogham/rust-users/blob/07bf842751d7f7ce1e9e342535d837c0e503e4f2/src/base.rs#L420-L445

Could just be the buffer is too small for your system?

[sklages]

This is still an issue with MOST RECENT VERSION: v0.9.0, released on July 15th

 $ exa --version
exa v0.9.0

Any solution for that yet?

I just discovered exa and really like it, but this issue would be a real game stopper for me, .. working in a multi-server/multi-user linux environment ...

lsdeluxe has the same issues for using rust as well ..

[Freaky]

If anyone wants to try with my fix, you can replace the users = line in Cargo.toml with:

users = { git = "https://github.com/Freaky/rust-users.git", branch = "handle-erange" }

[ariasuni]

@Freaky Can you open a PR on the ogham/rust-users repository?

[Freaky]

I did. Been in a release for the last 6 months.

[ariasuni]

Sorry, I didn’t check. ^^’

So your fix has been merged and is in rust-users 0.11.0, and exa started using rust-users 0.11.0 in 04e2d4c, so exa 0.10.0 has the fixed version of rust-users.

Can you try exa 0.10.0 and tell if it’s fixed for you?

[Freaky]

@sklages and @jeffrollin - can you give it another go? I only speculated that this was the issue, I didn't experience it myself.

[overdodactyl]

I'm still seeing UIDs/GIDs rather than names in exa v0.10.0 on CentOS Linux 7...is there any helpful info I can provide?

[sklages]

@Freaky .. cargo still installs v0.9.0 .. cargo with the master branch installs v0.11.0-pre .. anyway, with latest exo v0.11.0-pre it seems to work just as expected, I do not see any IDs anymore when using --long --group. I'd say problem bug fixed 👍

System: in-house made Linux, 64bit

But I must admit that I switched to lsd a while ago...

[ariasuni]

@sklages Thanks for the report! The crates.io issue is tracked here: #834

@overdodactyl I tried to compile exa on both CentOS 7 and OpenBSD 6.8 and it works, so I’m not sure how to diagnostic your problem…

[overdodactyl]

Thanks for checking @ariasuni. I just tried building it myself and things are working, but not if I use the release exa-linux-x86_64-musl-v0.10.0.zip. I was using that one due to #298

[ariasuni]

I have no problem using exa-linux-x86_64-musl-v0.10.0.zip either, but it’s interesting to know that this problem may be happening only with musl builds.

[ariasuni]

Does anyone here is using Active Directory with the users/groups only appearing as UID/GID not in /etc/passwd or /etc/groups? Someone opened #900 and hinted that it may be the reason.

Also, could you try to compile and test code from this Gist?
https://gist.github.com/ariasuni/0fda1d3fda4df9946e55d70038275a8a

1. Download rustup and run rustup default stable
2. Download files from Gist, put main.rs in a src folder
3. Run cargo run user followed by an UID that’s shown in exa, same with respectively cargo run group and a GID

---

I created a dynamic user with systemd, so it wasn’t in /etc/passwd, and it used a relatively high uid (64642), and it worked perfectly fine.

I tried to look at how ls is doing, and it uses getuser defined here, so both ls and exa uses {get,set,end}pwent. Maybe something’s wrong in how the user cache is implement in rust-users.

[eflyon]

In my case, #900, it was definitely a musl/rust-users issue. I fixed the issue by making a glibc build in a CentOS 7 VM and moving those binaries to the network in question.

After investigating, the musl issues page has an entry for NIS/LDAP/other user databases - LDAP is used to talk to Active Directory - which notes that

Up through 1.1.6, only the passwd/group files were supported for user and group database functionality. musl 1.1.7 added support for alternative backends via the NSCD protocol.

and links to a github repo for a library that lets musl use glibc's "name service switch" modules. I don't have the know-how to try making the necessary changes to rust-users.

[ariasuni]

After investigating, the musl issues page has an entry for NIS/LDAP/other user databases - LDAP is used to talk to Active Directory - which notes that

Up through 1.1.6, only the passwd/group files were supported for user and group database functionality. musl 1.1.7 added support for alternative backends via the NSCD protocol.

and links to a github repo for a library that lets musl use glibc's "name service switch" modules. I don't have the know-how to try making the necessary changes to rust-users.

I don’t think rust-users needs fixing. If I understand correctly, this is something to install and configure locally. If not, then maybe it’s possible to build exa with a different musl, but I’ll leave it to people who know this kind of stuff, because it seem like two very rare things to do with almost no information about on the web (building a Rust program with a different musl, and using something like musl-ncsd).

[tymcauley]

Does anyone here is using Active Directory with the users/groups only appearing as UID/GID not in /etc/passwd or /etc/groups? Someone opened #900 and hinted that it may be the reason.

Also, could you try to compile and test code from this Gist?
https://gist.github.com/ariasuni/0fda1d3fda4df9946e55d70038275a8a

1. Download [rustup](https://rustup.rs/) and run `rustup default stable`

2. Download files from Gist, put `main.rs` in a `src` folder

3. Run `cargo run user` followed by an UID that’s shown in exa, same with respectively `cargo run group` and a GID

I created a dynamic user with systemd, so it wasn’t in /etc/passwd, and it used a relatively high uid (64642), and it worked perfectly fine.

I tried to look at how ls is doing, and it uses getuser defined here, so both ls and exa uses {get,set,end}pwent. Maybe something’s wrong in how the user cache is implement in rust-users.

@ariasuni I just installed exa v0.10.1 (the musl release) on a CentOS 7 system, and ran into the same numeric UID/GID issue. I just gave this snippet a shot, and it correctly printed out valid user/group names given a UID/GID printed out by exa. Hooray! I also gave it some garbage UID/GID values, and it printed "result is null". Any other testing I could do?

Strangely enough, if I clone and build the v0.9.0 release, then the user/group names show up as expected (no UID/GIDs). I also tried the v0.10.0 musl release for good measure, and it also displayed UID/GIDs rather than names.

[tymcauley]

Another data point: I cloned the repo and built it myself with the default x86_64-unknown-linux-gnu target, and it works properly (user/group names, no UID/GIDs). Note that I wasn't able to use the x86_64-unknown-linux-gnu release binary as it required a glibc version not present on my system. So, this could come down to a bad interaction with musl libc.

Unfortunately I wasn't able to build the x86_64-unknown-linux-musl target myself due to linker errors.

[ariasuni]

If you want to build x86_64-unknown-linux-musl, then you need to install e.g. must-tools on Ubuntu (you want the package of your distribution that has the musl-gcc executable).

lsd seems to have the same issue as us (but it uses rust-users too): lsd-rs/lsd#374

There’s also an issue about musl on the rust-users GitHub: ogham/rust-users#14 (comment)

I don’t really time to make sense of all of these versions/musl or not/binary or compiled/OS combinations… The issue just seem very nebulous.

The thing I’d like to know is: is there a version of exa 0.10.1 or master, built from source, that fails to give names instead of UID/GID when it’s in /etc/passwd.

[ariasuni]

exa is unmaintained, see #1243.

Anyone still having this problem, do you have it with the active fork eza?

[ariasuni]

Closing this in favor of eza-community/eza#541