Please move the "$HOME/snap" directory to a less obtrusive location

Bug #1575053 reported by John Wang on 2016-04-26
This bug affects 971 people
Affects Status Importance Assigned to Milestone
Zygmunt Krynicki
snapd (Ubuntu)

Bug Description

Snap package developers should be encouraged to store user data according to the XDG Base Directory Specification [1][2].

I installed the "notes" app via snap on a Xenial desktop:

    sudo snap install notes

and launched it using the snap wrapper script "/snap/bin/notes". The script created a directory "$HOME/snap/notes/1", resulting in the placement of the directory named "snap" directly under my home directory, a situation that is undesirable for two reasons:

- The XDG spec calls for user data to be stored under "$HOME/.local/share" (or rather, that's the specified default when the environment variable XDG_DATA_HOME isn't explicitly set, and default installations of Ubuntu don't appear to set it) .

- It clashes with the directory naming style on my desktop systems. All directories located directly under $HOME that are not prefixed with a dot are named using Capital Case -- e.g. "Desktop", "Documents", "Pictures" -- a scheme which is consistent with the defaults defined in "/etc/xdg/user-dirs.defaults" from package "xdg-user-dirs". A directory under $HOME having an all-lowercase name introduces an ugly stylistic inconsistency and it complicates the navigation of directories in the shell when tab completion is case-sensitive.

Therefore snap packages should base the value of SNAP_USER_DATA on the value of XDG_DATA_HOME (or its specified default). For the "notes" snap, this would be "$HOME/.local/share/snap/notes/1".

If however the XDG spec is considered irrelevant to snap packages, please consider using a proper UNIX-style dot-prefixed directory, "$HOME/.snap".


If you don't want to see the snap folder, create a file named .hidden and in that file, type


You may need to reload your file manager to see the change.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in snapd (Ubuntu):
status: New → Confirmed
Michael Vogt (mvo) on 2017-01-27
Changed in snapd (Ubuntu):
importance: Undecided → Wishlist
Stephan Henningsen (zta77) wrote :

This should have higher priority as it really affects everyone using snap.

It is arrogant to think everyone want your ~/snap directory polluting their $HOME! It's cluttering my shell, file browser, everything! I can't even remember the last time I installed an app that pulled this stunt.

Of course this should be changed in accordance with XDG standards. As a minimum this should immediately be changed to ~/.snap. It's an easy fix and is easy to migrate as well.

It's 2017, come on.

John Wang (johnwang) wrote :

I agree with comment #2 on urgency. Although this issue has been prioritized as "Wishlist" it really must be addressed before snaps are rolled out as a stable production feature of desktop releases, otherwise the practice of storing data under "$HOME/snap" risks becoming effectively entrenched. The longer the practice persists and the more software is adapted as snap packages it becomes increasingly difficult to enact fundamental changes given the general tendency of developers to resist or postpone such changes.

Zygmunt Krynicki (zyga) wrote :

This is hard to achieve technically and conceptually.

First of all, snapd manages the $HOME/snap directory in non-trivial ways. Some of those include security profiles that carefully spell out the name of that directory or rules that select anything-but that directory.

Snap doesn't what customisations have happened in each users directory. The act of re-locatin the snap directory is non trivial and may include existing bind mounts that cannot be affected by a move/rename operation.

Lastly the directory is not a good fit for .local/share. Notice that while a snap application is running it is observing a $HOME variable set to $HOME/snap/$SNAP_NAME/$SNAP_REVISION. It therefore stores all the typical XDG classes of content (.local/.config/.cache) in that one spot.

Changed in snapd (Ubuntu):
status: Confirmed → Opinion
Changed in snapd:
status: New → Opinion
Or Schiro (orschiro) wrote :

It would be great if the user could define the default sub-directory for the "snap" folder.

See also:

Zygmunt, that's unfortunate to hear if what you are describing is a fundamental design principle of the snap ecosystem.

While I wouldn't advocate that a user customize their home environment in a way that arbitrarily goes against convention and standards, locations should at least be configurable for when there exists a good reason to do so (and in $HOME, a good reason includes "because that's how I want it"). In this case, the desire is better compliance with an established standard that has become quite popular. That's a good reason, IMO.

What happens under the snap folder is legitimately the business of snap/snapd, but where it's located in the $HOME filesystem should be configurable. If not, it should be placed somewhere that is legitimately manageable by the system and made accessible to users in a way controllable by them (or possibly the system administrator).

As an aside, your description of what basically seem to be "hard coded" paths for mounts and security policies explains a tangentially related problem I'm having with snaps - on my system I use a non-default location for $HOME, and that's messing up the 'carefully spelled out' security policies, apparently. That's a problem, because there's no guarantee that $HOME will be under /home on *nix systems, particularly on servers or genuinely multiuser systems. Though technically difficult, that possibility needs to be taken into account by the snap ecosystem.

Jamie Strandboge (jdstrand) wrote :


"As an aside, your description of what basically seem to be "hard coded"
paths for mounts and security policies explains a tangentially related
problem I'm having with snaps - on my system I use a non-default
location for $HOME, and that's messing up the 'carefully spelled out'
security policies, apparently. That's a problem, because there's no
guarantee that $HOME will be under /home on *nix systems, particularly
on servers or genuinely multiuser systems. Though technically
difficult, that possibility needs to be taken into account by the snap

That is a separate issue (bug #1620771) from this bug and is something that is tunable, though it could be made easier by snapd (which is why that bug is still open).

happydemic (happydemic) wrote :

@Zygmunt, understood, users can't customise the location.

But surely the location could be a hidden directory?

Snaps are supposed to make Ubuntu easier for non-techie users, not harder, and putting this data in a standard directory under $HOME does not pass the grandmother test. If I put snaps on my grandmother's machine, she is going to think there is a virus called snap in her Home directory. Users are going to drive sysadmins mad by accidentally deleting their configs.

Why not use .snap if snap's hybrid config data means the usual options (.local/share, .config) are unsuitable?

I hope someone will think about this again.

Zygmunt Krynicki (zyga) wrote :

I think we might explore this but as any transition it is tricky business (given that snapd can be rolled back to a version that doesn't understand this layout).

In the interest of experimenting I will try to make a demo branch that uses $HOME/.snap instead, I'll keep this bug updated with details as I go ahead.

John Wang (johnwang) wrote :

@zyga Excellent news, thank you. I'm sure when the initial directory choice was made the snap team was under pressure to meet product deadlines (Touch/phone/cloud) so deferring a better solution until later probably made sense then; an argument can be made for a mandatory $HOME/snap directory being acceptable under an embedded/tablet/phone environment where the user isn't generally intended to have direct access to their home directory, but such arguments are much less defensible on servers and desktops. Unfortunately that postponement led to end users having snap packages using $HOME/snap installed on their systems, making the problem henceforth even more complicated to address, and it was starting to look like the snap team was going to wash their hands of this altogether and leave us with this very un-Unix-like immutable intrusion into /home, the filesystem hierarchy traditionally delegated to management by users.

I think .snap makes sense. Let's socialize that on the snapcraft list
and if there is no good reason otherwise we will make that the committed
plan. Timelines will be up to the team, it's not as high priority as
other elements of the roadmap such as secure tab completion.


"Snaps are supposed to make Ubuntu easier for non-techie users, not harder, and putting this data in a standard directory under $HOME does not pass the grandmother test"

IIRC, the reason why ~/snap was chosen was precisely to pass "the grandmother test" since a snap's data is typically stored in ~/snap/<name>/.... Putting those files in a hidden directory (eg ~/.snap/<name>/...) means that "Grandma" may not be able to find as easily the document she just created.

That said, I see no reason why this cannot be revisited on the mailing list as Mark suggested.

Snap data is not expected to be accessed from $HOME anyway - each snap
will typically have its own way to display its own data. That's
certainly true on personal / convergence devices.


I followed a link from AskUbuntu to make a case for "$HOME/.snap" as the default directory.

But it looks like that's where things are headed, so I'm happy. :)

Changed in snapd (Ubuntu):
status: Opinion → Confirmed
Changed in snapd:
status: Opinion → Confirmed

I agree with comments #2 and #3 regarding the urgency of this issue. As John Wang points out, it would be best to address this issue before the current data location becomes entrenched once more snaps are rolled out.

In comment #11, Mark Shuttleworth suggested that “$HOME/.snap” makes sense. I too prefer placing snap user data in the “$HOME/.snap” location. But I notice that flatpak places flatpak user data in “$HOME/.local/share/flatpak” in accordance with the XDG spec. See So an argument could be made for placing snap user data in "$HOME/.local/share/snap" to conform with the XDG spec.

summary: - User data directory should conform to XDG Base Directory Specification
+ Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to
+ "$HOME/.local/share/snap" in accordance with the XDG spec)
no longer affects: snappy
Stego (stegomon) wrote :

Much wanted!

Stephan Henningsen (zta77) wrote :

Today I installed an app that had unfortunately been ported to snap. Again I found my $HOME soiled with that unwanted non-hidden directory.

Could this please be moved off the "wishlist" and get some attention?

John Lenton (chipaca) wrote :

We can't really do this in a way that won't have unwanted consequences before we have epochs. Those are coming sometime soon (work will start in the next few months, at least based on the discussion at the snappy sprint: see the second whiteboard on and possibly for context), and after that we should be able to do this change (concretely, move from ~/snap to ~/.snap) if we agreed we'd like it to be this way (I think we do) and we agree on how to make the transition (I don't think we have).

GizmoChicken (gizmochicken) wrote :

@John Lenton, Thanks much the information. Good to know that this is receiving consideration. Much appreciated!

I'm not certain how the "importance" scale works, or what actual effect has. But so this doesn't get lost in the mix and forgotten, would you please consider upgrading the importance from "wishlist" to either "medium" or "high"?

Oliver Grawert (ogra) wrote :

wishlist seems to be just fine ...


- Wishlist: Missing functionality.
    - If it is non-trivial to implement, it should rather be written as a feature specification ...

part of this feature specification is the work on epochs...

tags: added: julyshakedown
larpon (larpon) wrote :

This has made me drop snap. I am to decide what the visible folders of my home directory are. I'll start using it again when this is resolved.

Until then; the AppImage format is a great alternative for distributing your apps in a sandbox (and it mostly stays out of the users way)

d❤vid (kwill) wrote :

Workaround while waiting for the rename:

Create a text file called ~/.hidden and put the word "snap" inside it. "snap" will now be treated as a hidden folder by Nautilus.

When "~/snap" is automagically be moved to "~/.snap" or (hopefully) "~/.local/share/snap" you won't even notice :)


Tom (tom-lorinthe) wrote :

Last tip works really well for me: ~/.hidden file with snap in it ;)

monaxos (neotheo) wrote :

I tried Snap out today, but after seeing it clutter my home folder I immediately removed all Snap applications and uninstalled it. In my home directory, I like to have only my media and documents visible with all settings folders and such being hidden. Until now, most applications respect this and store their settings in folders with a . in front, or at least allow you to customize where settings are stored. Snap doesn't allow me to do this. Being unable to change this makes Snap unacceptable for me. I think it is highly unfortunate that the location where the settings are stored should be in such a garish way and can't be altered. I am also sensing a lot of hesitation from the developers in changing this behaviour citing that it is difficult. Nevertheless, I, and I suspect many others, won't use it unless this bug is fixed.

Zygmunt Krynicki (zyga) wrote :

Hello, snapd developer here.

I just want to clarify what is going on. Changing this in the source code is possible but not very easy as the value is spelled out in a very peculiar way in the apparmor profile for snap-confine and all the snaps. We will eventually get there bug we need to implement the epoch system first so that we can ensure that users who migrate to ~/.snap (or whatever else the path is) won't be able to go back to a version of snapd that doesn't understand this. This is the work that John referred to.

Oliver Grawert (ogra) wrote :

I'd like to note again that ~/snap is not just simply a configuration dir as some people here seem to think (else it would probably have been dot prefixed from the start), but ~/snap/<packagename> is the default dir where your snap stores data that you want to be user accessible, might put additional binaries, scripts etc you want to execute...

it is way more than a configuration dir, it is the fallback homedir for the snap if it does not use any interfaces, it is the place where downloads can end up without having to use any interfaces and last but not least it is the default workdir that user started snap applications run in (vs $HOME which a non snapped app without security confinement would use, with access to all your sensible data)...

all these bits will be completely hidden once that dir moves and we will have to explain to users that the output of that cli command they just used can only be found if they turn on hidden files in their file browser... or that the download they just did with that gui program ended up in a hidden space ...

while it might seem trivial to some to just move the dir name, there is a lot of conceptual work to be re-done and re-thought to not lose in security and usability when hiding it ...
(along with the fact that you can always roll back to any former snap or snapd version and due to the fully transactional nature of snaps this needs to be fully backwards compatible as zyga mentioned above) please be patient ;)

Jonatã Bolzan Loss (jbopen) wrote :

Hi Oliver

We certainly understand the implications of this. Just to consider: how will I explain to my grandmother that the photos she just downloaded (using a snap software) are not on her friendly Home folder /Download or /Pictures, but the photos are stored inside the <software name> folder that is inside the <snap> folder that is inside her Home folder...? You see...

Really, the solution is not hiding the snap folder, but maybe making the snap software being able to access the Home folder/content... I know that it's not secure as it is intended with Snap packages, but I think that all of us agree that considering the "~/snap/<sofwarename>/" as the Home folder is definitely not user-friendly.

For a geek or a developer it is Ok, but for regular users, they should just look at their files in home folder, with their usual subfolders, as beautiful and comfortable as it always was. Regular users should not know (they don't need to know and they will not want to know) about this snap stuff, they just want to download the application from Gnome Software and use it in their Home folder.

We are patient, don't get us wrong :D The actual behaviour is not bad, it is just ugly.

Thanks for your attention.

Oliver Grawert (ogra) wrote :

... "how will I explain to my grandmother that the photos she just downloaded (using a snap software) are not on her friendly Home folder /Download or /Pictures" ...

luckily when using the home interface (and hopefully once your granny starts using snaps the app integration will be at a level where it will ask for permissions in a popup (similar to UbuntuTouch, IOS and lately even andoid) once the app tries to download something for the first time), work is being done in gnome-software for this), this is exactly what happens nowadays ...

but there are still developers that do not want to use interfaces, there are still cli apps (and will ever be) that want to put their output into their $WORKDIR etc etc ...

when snap stated there was no other secure way to solve these issues, interfaces were still rare and initially limited, having bits visible in the file manager in $HOME/snap was a good compromise (and still is IMHO).

What i was reacting to is:

"...Until now, most applications respect this and store their settings in folders with a . in front..." from a former commenter ...

$HOME/snap is not a config dir (and if we do actual config-only dirs they would most likely land in $HOME/.config/snap or some such to properly adhere to the established filesystem standards), it is the snaps home and workdir for now and the one securely accessible space for developers that do not want their snaps (be it server, desktop or cli apps) to use interfaces.

Jamie Strandboge (jdstrand) wrote :

"Changing this in the source code is possible but not very easy as the value is spelled out in a very peculiar way in the apparmor profile for snap-confine and all the snaps."

Actually, this isn't particularly difficult in and of itself. We could simply drop the complicated bit in the home interface we have now that carves out the snap dir (since it won't be special any more_ then simply allow @{HOME}/.snap/... by default.

The problem is all the other details that Zygmunt and Oliver mentioned, plus other things (eg, do we allow both directories? If we allow both, what does that mean for the home interface? Do we allow compatibility symlinks? Do we do a data migration? Do we do data migration upon revert of the core snap? What happens to applications if the only core snap is reverted, if only the app snap is reverted, if both are reverted? How do we handle snaps that hard-code ~/snap/... instead of using $SNAP_USER_DATA and $SNAP_USER_COMMON (this might be more common than you think-- I know of a lot of examples that use getent/getpwent() for things-- they may then be depending on being able to just tack on 'snap/<name>/common'? These questions are just the ones OTOH, I'm sure there are others.

Like Oliver said, there is conceptual work. Whenever this is implemented, I very much expect bugs coming in for what Oliver mentioned: "my snap's data is not discoverable because it is in a hidden directory" (which was the reason why it is 'snap' now instead of '.snap'; we had the same debates on 'snap' vs '.snap' when decided on this long ago).

John Lenton (chipaca) wrote :

Oliver, the argument that ~/snap/<app> is “not just simply a configuration dir” isn't particularly good, I think, as the same could be said about the triple XDG directories for data, config and cache (all of which default to be hidden).

It is the nature of the confinement that we build that these directories cannot be relocatable by simply setting something in the user's environment, and so we need to find something that works for all users.

We've already agreed to move it, and are slowly taking the steps towards that. We'll get there.

On the subject of having access to e.g. XDG user directories, again it's tricky because they're relocatable by the user, but I think something like the phone's trusted helpers (like the content hub), which the flatpak people are now calling portals, are the way to handle that.

aaronfranke (arnfranke) wrote :

Rather than just moving it, please allow it to be configurable. Hard-coding anything is a very bad idea.

GizmoChicken (gizmochicken) wrote :

"Rather than just moving it, please allow it to be configurable. Hard-coding anything is a very bad idea."

With regard to a directory that is intended to be user accessible (as opposed to one that contains configuration files), I'm all for reconfigurability.

But with regard to the locations of pure configuration files, I hope (and assume) that they will be hard-coded to an appropriate location. I'd be perfectly content with the proposed “$HOME/.snap” location. But just to repeat, flatpak places flatpak user data in “$HOME/.local/share/flatpak” in accordance with the XDG spec. See So an argument could be made for placing snap user data in "$HOME/.local/share/snap" to conform with the XDG spec.

P.S. I realize that, from a developers point of view, this issue may seem trivial compared to the much more import issues that the developers are fixing. And I'm surprised that term "bikeshedding" hasn't been mentioned in this thread. But as you can see from the "heat" of this report, having a visible "snap" directory (with a lower case "s") being forcibly placed in the home directory is disturbing to many.

Speaking for myself, if snap requires a visible "Snap" directory to appear in my home directory (upper case "S" consistent with other visible default directories in my home directory), although not ideal, I could live with that. But I anticipate that many would continue to complain. So it would be better if the name of any visible directory appearing in home is configurable.

machrider (machrider) wrote :

I personally love it when half-baked projects drop shit in my home directory.

Chris Meyers (sulobanks) wrote :

+1 for moving the snap directory to a more standard place and hiding it. The way I see it, you have two choices for a folder like this (and all other software I use conforms to this):

1. Make it non-configurable and hide it in a standard, widely accepted location (~/.<whatever>, .local/<whatever>, .config/<whatever>)
2. Make it user-configurable.

Or you could get really crazy and do both.

But creating a visible, non-configurable folder directly in the user's home dir is just plain bad. You'll get nothing but complaints. People who don't like it there or want it spelled with an upper case 'S' or want to call it 'Applications' or something. This is actually worse than littering the file system with loop devices. :-P

Manuel Grießmayr (dccoder84) wrote :

Many thanks for polluting my home directory. Also if the snap directory isn't available my Home dir will be polluted with empty dirs like Downloads, Music, Pictures etc.

Oliver Grawert (ogra) wrote :

@manuel: this is definitely not happening on any of my systems and surely not normal (creating any of the XDG dirs i mean), are you sure you do not simply have a badly written snap that has the home interface connected and uses a broken startup script (you should talk to the snap developer in this case ... typically "snap info <snapname>" shows a "contact" field to find an address for this.

Seif Allah Tarhouni (saksow) wrote :

Very smart package manager, except for this very bad design. Please fix it, thanks.

Fanjin Zeng (fanjin) wrote :

This bug report has been opened for almost 2 years! It should be an easy fix!! Stop polluting my home directory, please fix. Thanks

Fanjin Zeng (fanjin) wrote :

I completely agree with @gizmochicken (#19), the importance of this bug is underrated. This is the second hottest bug in snapd, it has been opened for almost 2 years and is affecting every user. In fact, I have never seen any other open-source software occupying home directory without asking user permission (Even software in Windows system won't do this). I don't think this is just a 'Missing functionality' issue, such intrusive method is definitely hurting Snap's reputation. @neotheo (#24) is right, many people may not use snap again because of this.

Most of comments above agree on changing to '$HOME/.snap', I personally prefer '$HOME/.local/snap'. Either is much better than current location. I hope this will be fixed soon.

Gustavo Niemeyer (niemeyer) wrote :

This is the second hottest bug because it's very easy to have an opinion about it without any strings attached.

As I believe was explained multiple times above the real reason this is not "hidden" is that snap/ is not just a configuration directory. This is where the writable space for all snaps live. For them to be able to write anywhere else they need interfaces that would allow them to do so.

As a trivial example, this is content I have in my snap/ directory right now:

$ ls ~/snap/telegram-desktop/current/Downloads/*
VID-20180204-WA0007.mp4 VID-20180214-WA0008.mp4

Hiding this directory has an important unintended consequence which I'm sure you won't like either: it encourages packagers to use less strict confinement. For that specific reason, we won't change that just yet.

Instead, we're working on better ways to allow snaps to have access to read and write data in the system in a controlled way. After that happens, we WILL remove this directory from your homes into a better place.

Meanwhile, apologies for the inconvenience.

Changed in snapd:
status: Confirmed → Won't Fix
Changed in snapd (Ubuntu):
status: Confirmed → Opinion
Changed in snapd:
status: Won't Fix → Opinion
importance: Undecided → Wishlist
Changed in snapd:
status: Opinion → Confirmed
Changed in snapd (Ubuntu):
status: Opinion → Confirmed
summary: - Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to
- "$HOME/.local/share/snap" in accordance with the XDG spec)
+ Please move the "$HOME/snap" directory to a less obtrusive location
John Lenton (chipaca) on 2018-03-31
no longer affects: snappy
Jeremy Bicha (jbicha) on 2018-09-26
description: updated
information type: Public → Public Security
information type: Public Security → Private Security
information type: Private Security → Public
information type: Public → Public Security
information type: Public Security → Public
Yovan (jiabanster) on 2019-12-20
Changed in snapd (Fedora):
status: New → Invalid
no longer affects: snapd (Fedora)
164 comments hidden view all 244 comments
Andrew (coyotefoxtrot) wrote :

Yeah this comment thread has been going on for years. I am new to snap and will be quickly researching other alternatives such as flatpak and traditional installs for all my snaps so I can be snap-free. I can't believe people have been trying for years to get a simple problem fixed.

Andrew (coyotefoxtrot) wrote :

Happy 2020

Paweł Stołowski (stolowski) wrote :

Please do not spam this bug report with meaningless comments. Comments under bug reports should be limited to the merit and provide extra info where info is lacking, "me too" is not really bringing anything to the discussion.
It is understood that this issue is very important for some users. Zyga invested quite some time into investigating it, commented a couple of times and gave extensive explanation about why this is not an easy change. This problem is not a bug but a design decision and since it's not breaking snapd/snaps, it has been categorized as "Wishlist"; it isn't fixed not because we ignore it, but because our hands are full with other features, and of higher priority.

We hope for your understanding.

Ivan (copilot-language) wrote :

Sorry, but no.

As developers and apps creators, snaps are being pushed on us everywhere and cornering us into change practices and toolchains. This is a lot of time that we have to invest, not knowing whether it's going to pay off, because some company made a decision to vouch for yet another app distribution standard that sacrificed too many of the benefits we had way before it was ready.

It's perfectly reasonable that people let you know that something, while being functionally smaller in your opinion, is a decisive aspect for them.

It snap is based on a bad design, then the bug is much more serious than it seems because the design is broken, and we cannot rely on it.

Kyle Barbour (kylebarbour) wrote :

Given snap's many poor design choices, I was delighted to find that

$ sudo apt autoremove --purge snapd

had no disadvantages for me, and I recommend it highly to anyone who is able to avoid snap in their ecosystem. In addition to solving this home directory issue, it eliminates some of snap's other intentional clutter, such as bloating `df` and `cat /proc/partitions` with garbage.

Regarding unnecessary comments, I'm glad to see people standing up for themselves. Since the devteam's choices don't respect us, I think we have every right to return the favor. It seems to me that after 4 years, continuing to annoy them is one of the few options available to those who can't avoid snap altogether.

Wolfgang (wolfgang-v) wrote :

@stolowski Although it does not break snapd/snaps this design decision goes against well established standards and practices and causes issues for users in the host environment. Can you please point us to a place where we can escalate issues that cause problems in the bigger context?

I still cannot understand why the dev team would continuously deprioritize the issue with the most heat by far for such a long time.

Ivan (copilot-language) wrote :

I do not have a problem with the snap dev team deciding that this issue has no priority for them. That is absolutely fine. It an individual project, it's their project, nobody tells anyone else what to do with their time. To think that they owe us to fix it would be disrespectful imo.

But I do have a problem with Ubuntu promoting snaps then. I've been promoting and supporting the Ubuntu distribution for years, and creating tools that are compatible with it.

When a core tool changes, that's when it becomes *my* time. And the last few years have been particularly annoying.

I'm happy with this issue remaining unresolved forever, so long as Ubuntu stops installing snaps by default, and systematically promoting them.

Douby (jan-doubravsky) wrote :


I have to comment here too. Pawel, it is not as you mention "important for SOME users". That some (in fact many) people are people using Ubuntu but not even know where complain about this issue. Sorry but I cant easily deploy Ubuntu for normal users (PCs for older people, or PCs for only browsing, accounting, etc.) because few days after are calling me and have questions about strange "snap" folder and how to get rid of it. I had even few cases that this annoying bug made them go back to Windows. They are really sensitive where everything is and why.

It is simple, do it right (or hidden by default) or dont put it in Ubuntu by default.

eryksun (eryksun) wrote :

I take it as given that Snap and various use cases were considered important enough to use a top-level directory in $HOME. That said, you can call me a pedantic, persnickety, nitpicker, but I dislike the default name "$HOME/snap" and that it's not configurable. The default name should follow the existing title-case convention, and it should be plural for a directory that contains multiple instances of the item class -- e.g. Downloads, Pictures, Videos, and even Music (a mass noun). I don't see "Snap" as a mass noun for Snap packages, so the default name should be "$HOME/Snaps".

Thomas Perl (thp) wrote :

Were there already good reasons why it can't follow XDG, if only via symlinks?

Or if not, maybe there should be an updated XDG base dir specification that takes into account the requirements of Snap and Flatpak and other similar solutions?

Note that Desktop Linux isn't the only one having per-app directories, on macOS it's in "~/Library/Application Support" (and "Library" is hidden by default from Finder [file manager], but not in "ls") and on Windows it's "%HOME%/AppData" (again, hidden by default).

I got my system-installed Chromium package upgraded on 19.10, which pulled "snapd" back in (after I removed it a few days ago), so just "not using snap" isn't really an option for now (if on Ubuntu). Of course, Debian and Fedora provide a snap-less experience by default.

Given that third party vendors seem to prefer Flatpak, the Linux app updating experience gets more fragmented, from a simple "apt dist-upgrade" to an apt+flatpak+snap+whatever task.

At least Flatpak stores data in "$HOME/.var/app/" (from a visibility perspective), but that's still not XDG, so it's still bad.

Also, funny how the Chromium DEB->SNAP transition needed a folder migration (the blog post says "an existing Chrimium user profile will be imported [provided there is enough disk space]), this could have been so much simpler (and not potentially break users' profiles or require more free disk space than strictly necessary).

Given that there won't be The Single Solution for Linux app packaging, it would be cool if user data could be shared between Snap/Flatpak/DEB installations of an app. Then it's really a matter of "your DEB is too old? grab the Snap or Flatpak!", and not "oh well that's not compatible, you have to move files around and hope for the best". Also allows for switching between DEB/Snap/Flatpak seemlessly without "vendor lock-in".

dom (7-ubuntu-j) wrote :

So basically, since my /home have very limited space, I install everything on another HD,
that just mean I can't use snap because it install automatically and without possibility to choose another location ?

Bummer, it looked promising enough :(

Forest (foresto) wrote :

I discovered this today when the ubuntu 19.10 upgrade replaced my chromium package with a snap, thereby creating this alien directory in my home dir. I believe my exact words were, "are you fucking kidding me?"

> at the end it's pure aesthetics.

Wrong. It obstructs tab completion in command lines and keyboard navigation in file managers, which is something that I do thousands of times per day. This makes it a rather significant attack on usability.

Even for people who don't use keyboards, the additional clutter adds cognitive load every time someone looks for a file or navigates to another directory. It also contributes to pushing other files off the edge of file manager windows, thereby either requiring the user to scroll to find things or to waste desktop space with larger file manager windows. You might think these to be minor effects, but that doesn't excuse it, and they add up quickly. Especially for the single most visible directory in the entire system.

> echo snap >> ~/.hidden

That doesn't work my terminal or my Thunar (file manager) windows.

> "me too" is not really bringing anything to the discussion.

I normally agree, but this is a special case. It would be difficult to overstate how foolish this design decision was. The flood of comments serve as a clear demonstration of that, and will (hopefully) ensure that the people responsible think more carefully before repeating their mistake in the future.

Consider also that each "me too" here represents not just the person who wrote it, but also multiple others who had the same reaction but didn't bother (or don't know how) to come here and write about it.

While we're at it, not that there wouldn't be so many "me too" comments if the snap folks hadn't left this problem unaddressed for nearly four years.

Four. Years.

Okay, so fixing it properly is difficult because of your rigid design. Okay, that happens; we all make mistakes. But maybe consider implementing a temporary fix early, so you don't leave people burdened with your mistake while you take four freaking years to fix it properly?

I am in disbelief.

Amusingly, I happen to be evaluating container-style packaging systems this week, with FlatPak and Snap on my short list because of their sandboxing features. The fact that this bug exists in the first place, along with the fact that it has been allowed to persist for nearly four years, has convinced me: I'm not building anything with snap.

Forest (foresto) wrote :


Dear snap developers,

I do feel some empathy for you. You're trying to build something good, and share it with people. Taking heat while doing that mostly thankless job is tough. So, thank you for your efforts.

I chose not to censor my previous comment, though, because I have found that downplaying the significance of a problem is counterproductive in the long run. Things don't get fixed if the people who can fix them don't understand how problematic they are.

I can't wait another four years. Looks like I'm going to have to either find another way to use chromium on ubuntu, or else finally replace ubuntu.

Leon Matthews (leon-matthews) wrote :

@foresto You've done a good job of expressing my frustration with both the snap software, and the way it's being rolled out too.

Snap still 'smells' like experimental software to me - not a sold base for building an infrastructure upon.

This bug's namespace squatting in the home folder is the most egregious symptom, but let's not forget the horrors of running 'df' and 'fdisk -l' with snapd active! The pollution of home-folder backups is another that affects me (please let's not forget that not everybody has American-levels of band width and storage).

If we are sticking with snapd, can we please keep it entirely optional until it has matured a little more?

Wolfgang (wolfgang-v) wrote :

The dev team made it clear that for them it has no priority and from their point of view it is no bug and does not belong here. I actually really think that is a fair statement (although I really would love them to reconsider their point of view).

Does anybody know where the correct place is to discuss this further?

I have voiced my concerns directly to Ubuntu support last week as this might be the more appropriate channel for now. Although I thought they are listening here as well (see comment #11)

Zygmunt Krynicki (zyga) wrote :


We _do_ consider this to be a bug but it doesn't have priority that high for us to drop other things. We have a draft plan on how to address this (~/snap having any name and being optionally hidden entirely) but we are still catching up with development from the previous cycle.

It is likely this will be picked up after 20.04 as a new cycle starts.

Gustavo Niemeyer (niemeyer) wrote :

> The dev team made it clear that for them it has no priority and from
their point of view it is no bug and does not belong here.

I actually stated something else way back above. We care, and we'll fix it. It's not as straightforward as it sounds, though, and indeed there were higher priorities. It's okay to disagree with our priorities, though.. it's easy to have an opinion on this, harder to make everyone happy all the time.

> I have voiced my concerns directly to Ubuntu support last week

We already have some good ideas for how we want that feature to shape up, and I'm hoping we can have something in the next cycle after 20.04 is fully baked. I don't do priorities alone, though, so that's not a promise. Feel free to reach out to me directly in the forum or online elsewhere if you're interested.

chrm (ubuntu-one-3) wrote :

This bug has 3684 "heat". The next worst bug has just 614 heat. Both are almost four years old. Both are tagged as "wishlist".

One and a half year ago it was (paraphrased) "this fix is easy when the epoch feature is done" and (quote) "For the record, the epoch feature is being actively worked on and it's not that far hopefully".

Now (quote) "It is likely this will be picked up after 20.04 as a new cycle starts". Not certain, just likely.

To me this sounds like you are just pushing technical debt in front of you ad infinitum.

dorothea (dorothea2) wrote :

This bug and the severe cluttering of the output of `fdisk -l` and `df` have made me decide to switch to Debian at my earliest convenience. The discomfort snap causes is simply too great and judging from this bug they may take years to fix, if they're even going to be fixed at all. I simply do not have the time to implement and maintain all kinds of workarounds.

I might check back in a year or so to see if things have improved.

Having an unwanted folder in my home directory, combined with how long it takes to fix an issue that so many people find annoying, makes me stop using snap. I'm going to rewrite my system setup scripts to use other methods of installing software (even if that means scraping websites to find download urls). It's a pity.

I need to uninstall Gnome Calculator, because it keeps spamming my home folder with a "snap/" subdirectory. Fortunately, no other apps I use regularly have this bug. I'll look for a different calculator app.

Tom Hanlon (tomhanlon) wrote :

Agree with the comments here. /snap should not be polluting the home directory.

Robin Lundgren (linkert) wrote :

I agree with everything stated in comment #2 except that it's not 2017, *It's 2020, come on.*

Call me a superficial but I enjoy a nice and tidy home folder and this is the only reason why I go for the repos (currently on Void Linux) or in certain cases flatpaks over snaps. I would love to go for snaps. Just listened to episode 2 of season 13 of the Ubuntu Podcast where Popey had packaged up "ncspot" into a snap. I go to the ncspot github page and try installing it with cargo, the rust package thing and it fails with horrible error messages - no ncspot for me then.

Who do I pay and how much does the person in charge/responsible want to fix this? People all-over the planet will rejoice when this gets fixed.

Michael Jensen (mjensen-t) wrote :

I too have this problem. Please move the snap directory out of my home directory or make it .snap

Frederik Abitz (fabby3) wrote :

Hearing that this issue will only possibly, but not certainly be fixed after 20.04 is extremely disappointing to hear. I was planning on switching to Ubuntu for the upcoming LTS release, but after reading this I changed my plans.

I feel like this seemingly superficial, but practically important issue represents much of what is terrible about modern software. I like to call it narcissistic software. Software that is not only a useful tool, but behaves like it knows what's best for you. Sometimes to be different just because.

Whenever I see developers reacting to a rising complaint by telling the users THEY are wrong, especially when long-standing best practices are violated, I feel like the software is going to turn to shit in the long run.

Experimenting and breaking the rules is fine and can lead to great advancements, but many times it doesn't. This experiment is over. The results are in. Please just end it.

ralphb (dev-endlos) wrote :

Just how difficult can it be to rename the snap folder to ".snap"?

Ash Holland (sersorrel) wrote :

If you think it's so easy, why not try it yourself? snapd is free software, and I'm sure the maintainers would be grateful for a patch which fixes such a widely-shared issue.

alex (kredikshaw150) wrote :

It doesn't matter if it is difficult or easy. This issue has been going since 2017! it should be a priority.

Thomas Wehmöller (mordragt) wrote :

This is insane,
i am looking at this page like once in a month.... Since 2017, i really really want to use snaps. I have no words for this. I mean i get it, its more rewarding to implement new features over fixing old mistakes but just do the math. This are all the people that are so annoyed that they came here to express their disbelief, now think about all the users that are upset but dont find their way in here...

Emil Bøgh Harder (kasteklar) wrote :

Are there any official announcements of why they don't want to follow the XDG standards?

Zygmunt Krynicki (zyga) wrote :

Hey, a fellow snapd developer here. We do not use XDG locations for the following reasons:

1) They are configurable, per user, which would require per-user confinement that we currently do not support.

2) Ignoring that, the standard locations are not followed by *all* software uniformly so we need a location for things that do not fit XDG anyway. As an example, a snap of something like vim would use ~/.vim and ~/.vimrc outside of confinement. That would need mapping to _a_ path inside the confinement. We would have to have some form of ~/snap/vim/current/.vim anyway. Where would that go?

3) In addition to that, snapd manages application data and creates two distinct locations, the per-revision data set ~/snap/$SNAP_NAME/$SNAP_REVISION and ~/snap/$SNAP_NAME/common. This is essential to handle "snap revert" which rolls back both the application code and application data. There's no clear mapping of that to any of the XDG documented locations.

There may be additional reasons, I'd have to go back to my notes from the original design of this location many years ago. As a person who implements the lower-level parts of snapd, I can really say that doing anything about 1) is extremely hard and security sensitive.

Oliver Grawert (ogra) wrote :

To extend what zyga said above ...

A major amount of snaps are used on appliance, embedded, IoT and server devices (in fact snaps were used in these environments for two years already before they came to the desktop at all). On many of these systemd XDG doesnt even remotely play a role so it was originally not a big focus when snap development started in 2014...

Wolfgang (wolfgang-v) wrote :

My main issue is that the snap folder is visible in the file manager and on the command line by default. With .snap that would no longer be the case. Workarounds for all file managers / file dialogs / file listing commands are not always easy.

Is there any specific context in which it is important to have a snap folder that is visible by default? I just can't think of anything.

Even better (but just nice to have) would be any default location (even ~/snap) and the option to set a configuration file in e.g. /etc/snapd/ that allows to set a custom path that is read and interpreted during re-installation. This way regular users / users that don't bother don't have to do anything and all other users can make their own decision.

As you can see from the previous paragraph I am sadly not a very savvy developer. But I am very curious to know: Would the effort to migrate to another hardcoded location than the current one (e.g. ~/.snap) be more, less or similar to the effort with a user-configurable location?

Zygmunt Krynicki (zyga) wrote :

I understand the sentiment with ~/snap being a fixed location, shared by both yourself and other people who have commented here.

The cost of making ~/snap arbitrary is very high but we have some ideas that we are actively exploring as a part of the 20.10 cycle planning and I suspect there will be some exciting updates to share once the plans are more solid.

Zygmunt Krynicki (zyga) wrote :

To be clear, we've agreed to work on this in our cycle that runs for the next 6 months.

It's happening! :)

Changed in snapd:
importance: Wishlist → High
assignee: nobody → Zygmunt Krynicki (zyga)
GizmoChicken (gizmochicken) wrote :



tellapu (tellapu) wrote :

@zyga Wonderful! Thanks in advance for working on this!

bitboy (zeus557) wrote :

I didn't read all posts and i used snap yesterday for the first time.
I installed League of Legends which worked after a few tries, so great work. But my system has 2 hard drives, a fast (and small) SSD for system data and a classic one for large data. Now League of legends is about 10 Gb in my home dir which fills up the space and i'm not able to move the folder to my larger hard disk. This is a show stopper.

As i'm new to snap, this way it isn't possible to share a snap to a second user on the same machine. So if someone else wants to play lol too, it will cost another 10Gb i guess...

Oliver Grawert (ogra) wrote :

to move the content of the dir you might be able to:

stop all snap apps ...

mv ~/snap /whereever/your/bigger/disk/is/mounted
mkdir ~/snap
sudo mount --bind /whereever/your/bigger/disk/is/mounted/snap ~/snap

you might need to adjust permissions on the target disk, the snap dir must be fully read/write for the user using it ... and can indeed create a systemd mount unit to make this permanent ...

bitboy (zeus557) wrote :

thx that worked. Its required that your user is owner of the snap folder. A bit complicated to realise on an ntfs partition but possible.

Displaying first 40 and last 40 comments. View all 244 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers