Folders not visible with ls in alpine base images

Running containers on a Resin stack with alpine as the base image appears to make folder names invisible to ls commands in the Resin terminal. I think by default alpine is using a color scheme for ls that Resin terminal does not display? This includes the official resin/raspberrypi3-alpine container.

I know the folders are there because I can copy the blank space in my screenshot and paste it into a text editor to see the folder names.

Example screenshot:


Example dockerfile:

FROM resin/raspberrypi3-alpine

# set timezone
RUN apk add --no-cache tzdata
ENV TZ=America/Toronto

# install git, openssh, and rsync
RUN apk add --no-cache \
	openssh \

# adjust sshd config
RUN sed -i \
	-e 's/#PasswordAuthentication yes/PasswordAuthentication no/' \
	-e 's/#GatewayPorts no/GatewayPorts yes/' \

COPY /usr/bin/

CMD [ "/usr/bin/" ]

Has anyone else experienced this? Is there a preferred way to set the term color in alpine that will fix display issues in the Resin terminal?

I wasn’t able to reproduce the issue using the Dockerfile you provided as a basis. Could you please use a specific version for the base image so that we can track this better and force a rebuild.
Does the issue persist if you use FROM resin/raspberrypi3-alpine:3.6 for example?

@thgreasi I can still reproduce it with multiple images using resin/raspberrypi3-alpine:3.6 as a base image.

Here’s my resin stack, in case it’s something in my script that I’m overlooking. Both of the images in the stack use the same resin/raspberrypi3-alpine:3.6 base image, but have slightly different packages and start scripts.

I think the same thing happened with the non-resin alpine images as well, but I would have to double-check in case I’m remembering wrong.

UPDATE: This only happens in Firefox 59.0.3 (64-bit) and maybe other releases.
I tested in Google Chrome Version 66.0.3359.139 (Official Build) (64-bit) and all the folder names were visible.
Again, more of a weird issue than a show-stopper. Obviously the containers are still completely operational.

Hi @klutchell Thanks for the report!
I’ve added this problem to our bug queue for the dashboard, and will update this post once we’ve resolved the issue.