[GH-ISSUE #210] Running dust in ~ gives error message "Did not have permissions for all directories" #98

New Issue

2026-06-08T11:25:40+03:00

zhus commented

2026-06-08 11:25:40 +03:00

Originally created by @drhumlen on GitHub (Feb 1, 2022).
Original GitHub issue: https://github.com/bootandy/dust/issues/210

First time I ran dust I chose deny when it asked for permission to a bunch of directories. Now that I've used the tool for a while, I want to grant it permission to those directories, but there's no way to grant it permission now? I even tried brew uninstall dust and then re-installing it, but it still doesn't prompt me for permission again.

Originally created by @drhumlen on GitHub (Feb 1, 2022). Original GitHub issue: https://github.com/bootandy/dust/issues/210 First time I ran dust I chose deny when it asked for permission to a bunch of directories. Now that I've used the tool for a while, I want to grant it permission to those directories, but there's no way to grant it permission now? I even tried `brew uninstall dust` and then re-installing it, but it still doesn't prompt me for permission again.

zhus closed this issue

2026-06-08 11:25:40 +03:00

zhus commented

2026-06-08 11:25:41 +03:00

@peterjc commented on GitHub (Feb 9, 2022):

Was this on macOS?

@peterjc commented on GitHub (Feb 9, 2022): Was this on macOS?

zhus commented

2026-06-08 11:25:41 +03:00

@drhumlen commented on GitHub (Feb 13, 2022):

@peterjc Yes

@drhumlen commented on GitHub (Feb 13, 2022): @peterjc Yes

zhus commented

2026-06-08 11:25:41 +03:00

@bootandy commented on GitHub (Feb 16, 2022):

That sounds like a mac system level problem .

Try either:

Run as root: sudo dust.
Find the permission which will be saved somewhere in mac settings and grant it.

@bootandy commented on GitHub (Feb 16, 2022): That sounds like a mac system level problem . Try either: 1) Run as root: `sudo dust`. 2) Find the permission which will be saved somewhere in mac settings and grant it.

zhus commented

2026-06-08 11:25:41 +03:00

@hamzamohdzubair commented on GitHub (Dec 16, 2022):

i have the same issue on linux, cannot run sudo dust, because dust is not installed on root

@hamzamohdzubair commented on GitHub (Dec 16, 2022): i have the same issue on linux, cannot run `sudo dust`, because dust is not installed on root

zhus commented

2026-06-08 11:25:41 +03:00

@AnkushMalaker commented on GitHub (Mar 19, 2023):

@hamzamohdzubair
You can use
which dust
from your normal user where dust is installed, and then run sudo /home/<user>/.cargo/bin/dust, for example.

In my case, I still got the Did not have permissions for all directories error and I'm running ubuntu.

@AnkushMalaker commented on GitHub (Mar 19, 2023): @hamzamohdzubair You can use\ `which dust`\ from your normal user where dust is installed, and then run `sudo /home/<user>/.cargo/bin/dust`, for example. In my case, I still got the `Did not have permissions for all directories` error and I'm running ubuntu.

zhus commented

2026-06-08 11:25:41 +03:00

@Burnus commented on GitHub (Jun 14, 2023):

I have the same issue on MacOS. Running with sudo produces the same error. Would be nice if dust could tell me which directory it has an issue with.

@Burnus commented on GitHub (Jun 14, 2023): I have the same issue on MacOS. Running with `sudo` produces the same error. Would be nice if dust could tell me **which** directory it has an issue with.

zhus commented

2026-06-08 11:25:41 +03:00

@bootandy commented on GitHub (Jul 13, 2023):

There are often a huge number of directories that it did not have permission for. However, your point it noted I'll leave this as a todo.

@bootandy commented on GitHub (Jul 13, 2023): There are often a huge number of directories that it did not have permission for. However, your point it noted I'll leave this as a todo.

zhus commented

2026-06-08 11:25:41 +03:00

@Burnus commented on GitHub (Jul 13, 2023):

FWIW, my issue turned out to actually be broken permissions on some directory, not a bug in dust. Still, calling out the offending path in the error message would have made it easier to pin this down.

@Burnus commented on GitHub (Jul 13, 2023): FWIW, my issue turned out to actually be broken permissions on some directory, not a bug in dust. Still, calling out the offending path in the error message would have made it easier to pin this down.

zhus commented

2026-06-08 11:25:41 +03:00

@DianaNites commented on GitHub (Jul 13, 2023):

I also get this on linux and can't figure out what path it is, as far as I can tell its fine but i could be missing something, having an option to list the erroring paths it encounters would really help.

@DianaNites commented on GitHub (Jul 13, 2023): I also get this on linux and can't figure out what path it is, as far as I can tell its fine but i could be missing something, having an option to list the erroring paths it encounters would really help.

zhus commented

2026-06-08 11:25:41 +03:00

@MithicSpirit commented on GitHub (Jul 15, 2023):

Running a command like find . >/dev/null can be helpful for spotting the permission error. This discards stdout so all that's left are the errors in stderr, which should all be permission errors. As for adding support for showing the permission errors directly in dust it would be nice if it was kept behind a CLI flag (and printed to stderr instead of stdout).

@MithicSpirit commented on GitHub (Jul 15, 2023): Running a command like `find . >/dev/null` can be helpful for spotting the permission error. This discards stdout so all that's left are the errors in stderr, which should all be permission errors. As for adding support for showing the permission errors directly in dust it would be nice if it was kept behind a CLI flag (and printed to stderr instead of stdout).

zhus commented

2026-06-08 11:25:41 +03:00

@Burnus commented on GitHub (Jul 15, 2023):

Running a command like find . >/dev/null can be helpful for spotting the permission error. This discards stdout so all that's left are the errors in stderr, which should all be permission errors.

I know. That's basically what I ended up doing. Still, this can take a very long time on large data sets and/or slow disks and I think it's unnecessary since dust must already have identified the offending directory.

As for adding support for showing the permission errors directly in dust it would be nice if it was kept behind a CLI flag (and printed to stderr instead of stdout).

The message is already being printed to stderr and nobody advertised for changing that. As for the feature flag, I fail to understand what advantage this would provide. Does anyone prefer the generic error message over a specific one? Would there be a significant difference in runtime performance between the two approaches once you already support it on a type system level?

@Burnus commented on GitHub (Jul 15, 2023): > Running a command like `find . >/dev/null` can be helpful for spotting the permission error. This discards stdout so all that's left are the errors in stderr, which should all be permission errors. I know. That's basically what I ended up doing. Still, this can take a very long time on large data sets and/or slow disks and I think it's unnecessary since dust must already have identified the offending directory. > As for adding support for showing the permission errors directly in dust it would be nice if it was kept behind a CLI flag (and printed to stderr instead of stdout). The message is already being printed to stderr and nobody advertised for changing that. As for the feature flag, I fail to understand what advantage this would provide. Does anyone prefer the generic error message over a specific one? Would there be a significant difference in runtime performance between the two approaches once you already support it on a type system level?

zhus commented

2026-06-08 11:25:41 +03:00

@lweiner-spirent commented on GitHub (Jul 25, 2023):

I am running on Linux (Ubuntu) as root, and have the error on a user directory.

The problem is this: the .ssh directory - to be functional for ssh usage - is required to have permissions for owner only... i.e. "chmod 0755 .ssh" or "chmod u=rwx,go-rwx .ssh".

In this case, the permissions are correct, root can read the files, but dust refuses to.

This behavior seems incorrect, inconsistent, and unpredictable (after trying a few tests) when used as root.

# id
uid=0(root) gid=0(root) groups=0(root)

# du -sh .ssh
24K     .ssh
# dust .ssh
Did not have permissions for all directories
 4.0K ┌── .ssh│█████████████████████████████████████████████████████████████████████████████████████████████████████████████████ │ 100%
# sudo dust .ssh
Did not have permissions for all directories
 4.0K ┌── .ssh│█████████████████████████████████████████████████████████████████████████████████████████████████████████████████ │ 100%

# du -sh .
4.4G    .
# dust .
Did not have permissions for all directories
 4.0K ┌── .│████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ │ 100%

@lweiner-spirent commented on GitHub (Jul 25, 2023): I am running on Linux (Ubuntu) as root, and have the error on a user directory. The problem is this: the .ssh directory - to be functional for ssh usage - is required to have permissions for owner only... i.e. "`chmod 0755 .ssh`" or "`chmod u=rwx,go-rwx .ssh`". In this case, the permissions are correct, root **can** read the files, but dust refuses to. This behavior seems incorrect, inconsistent, and unpredictable (after trying a few tests) when used as root. --- ``` # id uid=0(root) gid=0(root) groups=0(root) ``` --- ``` # du -sh .ssh 24K .ssh # dust .ssh Did not have permissions for all directories 4.0K ┌── .ssh│█████████████████████████████████████████████████████████████████████████████████████████████████████████████████ │ 100% # sudo dust .ssh Did not have permissions for all directories 4.0K ┌── .ssh│█████████████████████████████████████████████████████████████████████████████████████████████████████████████████ │ 100% ``` --- ``` # du -sh . 4.4G . # dust . Did not have permissions for all directories 4.0K ┌── .│████████████████████████████████████████████████████████████████████████████████████████████████████████████████████ │ 100% ```

zhus commented

2026-06-08 11:25:41 +03:00

@DianaNites commented on GitHub (Aug 13, 2023):

Dust will incorrectly give this error whenever it is provided both a path and an exclusion

reproducer

$ mkdir -p /tmp/dust/dir/ignore/me
$ dust /tmp/dust/dir/
0B     ┌── me  │                █ │   0%
0B   ┌─┴ ignore│                █ │   0%
0B ┌─┴ dir     │                █ │   0%

$ dust /tmp/dust/dir/ -X ignore
Did not have permissions for all directories
0B     ┌── me  │                 █ │   0%
0B   ┌─┴ ignore│                 █ │   0%
0B ┌─┴ dir     │                 █ │   0%

$ dust /tmp/dust/dir/ -X /tmp/dust/dir/ignore
Did not have permissions for all directories
0B     ┌── me  │                 █ │   0%
0B   ┌─┴ ignore│                 █ │   0%
0B ┌─┴ dir     │                 █ │   0%

You'll notice it will also not actually exclude the path, no matter how you specify it.

It will still error even if the excluded path does not exist.

@DianaNites commented on GitHub (Aug 13, 2023): Dust will incorrectly give this error whenever it is provided both a path and an exclusion reproducer ```bash $ mkdir -p /tmp/dust/dir/ignore/me $ dust /tmp/dust/dir/ 0B ┌── me │ █ │ 0% 0B ┌─┴ ignore│ █ │ 0% 0B ┌─┴ dir │ █ │ 0% $ dust /tmp/dust/dir/ -X ignore Did not have permissions for all directories 0B ┌── me │ █ │ 0% 0B ┌─┴ ignore│ █ │ 0% 0B ┌─┴ dir │ █ │ 0% $ dust /tmp/dust/dir/ -X /tmp/dust/dir/ignore Did not have permissions for all directories 0B ┌── me │ █ │ 0% 0B ┌─┴ ignore│ █ │ 0% 0B ┌─┴ dir │ █ │ 0% ``` You'll notice it will also not actually exclude the path, no matter how you specify it. It will still error even if the excluded path does not exist.

zhus commented

2026-06-08 11:25:41 +03:00

@bootandy commented on GitHub (Aug 26, 2023):

I can reproduce your issue DianaNites - I'll look at this.

Edit: No I've forgotten how to use my own tool!

Run like this:
dust -X /tmp/dust/dir/ignore /tmp/dust/dir/

if you run:
dust /tmp/dust/dir/ -X /tmp/dust/dir/ignore

dust will look for 3 directories called: /tmp/dust/dir/, -X, /tmp/dust/dir/ignore and it won't find -X and so it will print 'Did not have permissions for all directories'.

@bootandy commented on GitHub (Aug 26, 2023): I can reproduce your issue DianaNites - I'll look at this. Edit: No I've forgotten how to use my own tool! Run like this: `dust -X /tmp/dust/dir/ignore /tmp/dust/dir/` if you run: `dust /tmp/dust/dir/ -X /tmp/dust/dir/ignore` dust will look for 3 directories called: `/tmp/dust/dir/`, `-X`, `/tmp/dust/dir/ignore` and it won't find `-X` and so it will print 'Did not have permissions for all directories'.

zhus referenced this issue

2026-06-08 11:26:58 +03:00

[PR #98] [CLOSED] docs(readme): add homebrew installation cmd #303

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bootandy/archived-dust#98