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

Bug #1575053 reported by John Wang on 2016-04-26
This bug affects 680 people
Affects Status Importance Assigned to Milestone
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
102 comments hidden view all 182 comments
Salvador Diaz (salvadordiaz) wrote :

I've been using ubuntu since its first version and I've put up with some unfortunate decisions through all those releases because trade-offs always seemed to be worth it, and not once I've been tempted to be rude to ubuntu developers.

That changed today when I finally decided to investigate what was in that ~/snap folder and why it was constantly reappearing in my home folder and I found this bug report. I get that you made some wrong assumptions and now it's hard to change the initial design, but I just don't get how you can openly talk down to seriously frustrated users and downplay the issue for more than two years.

Anyway... for those of you wondering how to get rid of these folders, just remove snap:

sudo apt-get remove --purge snapd gnome-software-plugin-snap

If you're on a fresh ubuntu 18.10 install, you might want to install the non-snap versions of the couple of system apps that were installed by default using snap:

sudo apt-get install gnome-system-monitor gnome-calculator

Carl Best (cbest786) wrote :

A lot of discussion about moving the directory to .snap or .local. I would be happy is for all that is sacred if they are not going to hide it since data can be stored there PLEASE just capitalize it like every other visible folder in my home folder:


Whats so hard about being consistent so it does not immediately make me zero in on it and go ... one ... and only one of these is not like the other one.

\snap <------------

Daniel Stoyanov (dankh) wrote :

I went the sudo apt remove way. I'm like many Ubuntu users, creature of habits and obsessions. The $HOME is really a home for me, I like it tidy in clean. I can't stand somebody putting a shelf in the middle of my room and "deal with it" ... I love Ubuntu so please remove this shelf off my room and put it in the closet.

Gustavo Niemeyer (niemeyer) wrote :

Hi Carl,

This is likely what we will do indeed, as it's a nice partner to the other standard options already there, is language-agnostic, and thus easier to handle on the confinement sense. We'll also clean it up a bit on the way, by stashing the non-current revisions in a better place. (deckoff) wrote :

I hope this is some kind of a tasteless joke.... If you really, really, really insist on having a visible folder inside the home dir, you can just create a ln - Snap linking to .snap (or whatever the real folder would be). I wont repeat everyone, but totally agree with them

Carl Best (cbest786) wrote :

Not really a joke.

Its the more reasonable approach. As someone already stated its not just configuration in the snap directory ... snap apps also seem (whether I agree with whether the SHOULD) to store data in the snap directory. My Videos are data. My Downloads are data. My Documents are data. Why cant snap apps store data in the Snap directory. Now an even MORE reasonable variant would be to put CONFIGURATION in .snap/<AppName> and DATA in Snap/<AppName>. Apps that don't need to store data .... like the darn Calculator (come on .... please .... its a calculator if it needs temp files use /tmp) can just put config in .snap and not create the Snap directory at all. It IS a little ridiculous that every time i start the calculator it get a snap directory.

Now ... don't get me wrong ... in a more ideal world (which I almost never get to live in in the not quite 30 years I have been writing software) you would put all data in the existing data directories where grandma knows where it is already .... and put config in .snap/<AppName> and call it a day. We, however, do not live in an ideal world and should, when POSSIBLE, compromise. For some people compromise seems to be a dirty word.

When its a matter or principle you stand like an oak. When its a matter of style, bend like a willow. The problem is .... when you think EVERYTHING is principle.

Davide (davide-cester) wrote :

@Carl: "Why cant snap apps store data in the Snap directory."
Because it's not intuitive, it's not descriptive, it's not configurable. My Videos contains videos, Snap contains... what? I can delete My Videos and move my videos, but I can't delete Snap directory (unless I totally stop using snap).

My girlfriend recently moved to Ubuntu from another system, her second question was "what is that folder in my home? I never installed any application named Snap". Sorry, it's just a bad choice. I can accept if developers say "we don't have the resources to change it" or even "we don't care" but "why can't you all forget your standards and best practices" does not sound totally right to me...

LN (lninja) wrote :

What a shame. Purged snap until the issue is fixed.

Seconding #150, I'm not using snap until this is fixed. The explanations of whys and wherefores indicate to me that snap as a software development project is beset by bad development practices.

Stephan Burkhalter (stephbur) wrote :

Also removed snapd. I cannot believe this is still a thing after almost 3 years of this bug being reported. I troubles me very much, that the devs do not seem to take this issue seriously (enough). I hope developers are going to reconsider putting everything in .snap.

I really don't understand why one should put user data in the snap directory. What if I have a project that uses snap AppFoo and AppBar? Then I will find my files in ~/snap/AppFoo/data and ~/snap/AppBar/data instead of together in ~/MyProject?

Viktoria Nemkin (nemkin) wrote :

Also removed snapd. I cannot believe this package is by default part of the current LTS installation of Ubuntu.

Viktoria Nemkin (nemkin) wrote :

As it stands right now, this bug has the most heat from all snapd bugs, more than 3 times as much as the next one:

Yet, it's marked as 'Wishlist' and has been untouched for 3 years.

@nemkin this "bug" touches core snap architecture. Fixing it will need a lot of work and at the end it's pure aesthetics.

Viktoria Nemkin (nemkin) wrote :

@francescohickle15 People care about aesthetics. Many of them, including me, uninstall snap because of this. You are right, this is not a bug. This is bad design at the core of snap's architecture.

Oleg (thealik) wrote :

@francescohickle15, this is not "pure aesthetics".

Creating random folder in user's home directly, without user explicitly requesting it is just bad design. Not giving user any option to remove/move or even rename this folder is a horrible design choice and has nothing to do with aesthetics. As many people here mentioned is has multitude of negative consequences and I'm not sure why Snap developers keep ignoring this critical issue while hiding behind "it is hard to fix and we like it this way" argument.

Gustavo Niemeyer (niemeyer) wrote :


We have been working non-stop on snapd over those three years, including features that will improve the situation for this folder. The fact it is marked as Wishlist reflects more on the fact nothing is in fact broken, other than you and me would both like to have a nicer folder structure.

The fact this bug has the most heat also reflects on how easy it is to have an opinion about it

Don't get me wrong, though. We will do better here for sure.

Oleg (thealik) wrote :

I don't think it is fair to attribute popularity of this bug to the law of triviality.
IMO it generates so much heat because it is directly visible to the end user and also affects everyone, regardless of what snaps you use.

It is nice to hear that there are still plans to fix this though.

Mark Hamblin (5-mark-8) wrote :

May I humbly request this bug be raised up the priority list to be fixed. My linux knowledge is small in comparison to many of the folks here,.. but it be gratefully appreciated if this issue could be resolved, as 'df' listings are loosing their impact and clarity as they are being cluttered by the inclusion of 'snaps'.
many tx

Justin Roberts (tjten5500) wrote :

I agree that this is poor design and will be uninstalling snap until this is fixed.

Alex Meakins (cnlpepper) wrote :

Creating a random first class folder in my home directory is intensely irritating, it is just junk that gets in the way of tab completion. I have no need to enter that folder every day, quite unlike every other non-hidden folder in my home directory. It should simply not be there. This can't take more than a few minutes to fix surely?

I'm reading the response from the snap dev with considerable incredulity. A developer working on a public facing project, frankly insulting users making a serious request that about a behaviour that is undesired.

Snap is a solution seeking a problem. All it is doing is complicating system administration for minor gain. Tried doing a "df -h" lately? It's now full of 10s of loop back entries, none of which are useful, all stupid snap mounts. Given the intention to expand usage this is going to scale until the basic disk space command "df -h" (among others) will be unusable without filtering the results.

I think perhaps less arrogance and more looking at the wider user impact of design decision would be more appropriate. You want this to be a success, start by NOT irritating your users.

Removing snap here too. I've said this before: I think snap should not be installed by default in Ubuntu LTS. The calculator should not be a snap. It takes way too much space and takes too long to start.

People can install snap if they want: the software manager is trivial to use, even computer-illiterate users can use it.

Ubuntu could even offer to install snapd when someone tries to install a snap, and everyone would be happy.

Oliver Grawert (ogra) wrote :

> It takes way too much space

Snap packages are by a *significant amount* smaller than their deb packaged equivalent, they are shipped as highly compressed read-only squashfs files that do not get unpacked but loop mounted on the host. typically a snap only uses about 30% of disk-space compared to the same amount of files/software shipped as deb packages. i'm not sure who came up with the claim that snaps are bigger, but this is definitely a completely wrong accusation.

The standard installation of snap, with no custom snap apps installed other than what Ubuntu installs by default, takes 1.6GB of hard disk on my machine.

Snaps themselves may be smaller to download, but keeping these things installed takes more space.

After purging snap completely, I just tried to install just gnome-calculator with snap.

$ sudo aptitude install snapd
(some output)

$ snap install gnome-calculator
2019-01-15T09:32:40-05:00 INFO Waiting for restart...
Automatically connect eligible plugs and slots of snap "gnome-calculator"

$ sudo du -sh /snap
489M /snap/

If you run the calculator, then this happens:

$ sudo du -sh /snap/
1.1G /snap/

Is this really lighter than installing it with apt-get?

$ apt-cache --no-all-versions show gnome-calculator | grep '^Size: '
Size: 253432

Unless I am very much mistaken, those are bytes.

And, just for completion:

$ sudo du -sh /snap/gnome-calculator/
7.3M /snap/gnome-calculator/

Which is, still, more than the space that the gnome-calculator takes when unpacked from the deb.

Oliver Grawert (ogra) wrote :

you are measuring the content of a mount point, not the on-disk footprint...

feel free to go on discussing on, this is off-topic for this already way too noisy bug ...

Oliver Lorton (olorton) wrote :

I'm in the process of switching away from MacOS to a Linux DE and I've created a lauchpad account just to register my frustration at this bug. I've just tried out snaps for the first time and after installing pycharm-professional have discovered the snaps folder contains nothing but config data. Well, actually it just seems to have a version numbered folder symlinked to a 'current' folder. This should be stored according to the XDG Base Directory Specification

$ du -s ~/snap
16 /home/oliver/snap

My feeling is that this issue should have been tackled when it was raised in 2016. Specifically, the OP's suggestion that _still_ stands: Snap package developers should be encouraged to store user data according to the XDG Base Directory Specification.

However, it's 2019 now and there are apparently over 1000 snaps in the wild. I wouldn't want the task of fixing this. After reading this thread it's also apparent that devs see this as a trivial issue, marking it as 'Whishlist'. So, like others here my only conclusion is that I'll have to purge the snap environment from my system.

I'm so disappointed that the snap system is flawed in this way and is becoming harder to move away from with every snap package that is created.

Gustavo Niemeyer (niemeyer) wrote :

The fix for one snap or ten thousand is exactly the same, as we're addressing this inside snapd proper. No snaps will need to change.

Pavel Dolinin (pavel-dolinin) wrote :

Please make it configurable.

Hi all,

I see the reasoning behind #40, it is about having an isolated interface between snaps and the normal world. But making the directory configurable shouldn't pose a problem at all. My favorite long term solution is that the folder lives somewhere else (maybe /snap/interchange/<user>/) similar to /media and file managers have a shortcut in the side bar.


iBART (mogio) wrote :

It "affects" me too.

Daniel Giguere (daniel.gig) wrote :

Create an account just to say it affect me too.

Purged snap until it's fixed.

Daniel Giguere (daniel.gig) wrote :

Do note that this bugs as the most heat of all snapd bugs, more than 4 times the value of second next highest heat bug. This should make it a priority.

Alex Corbin (comicsads) wrote :

Just made/realized I had a launchpad account for this. I love snapd but I'm tired of seeing the ~/snap directory pop up so much that I added a line to my bashrc to notify me if it shows up again. I'll likely be reinstalling snaps once this gets fixed, but I do want to say one thing to the developers. when a problem has 5 times as much "heat" as the next largest complaint, your userbase probably cares a lot about it, and it comes off as pretty disrespectful for you to just pass it off as an example of the Law of triviality. IMO, this should have been done soon after this bug was posted, and symlinks of some kind for each snaps download folders and such.
That being said, I have barely looked at the snap code at all, and would like to ask the developers why just grepping for every @{HOME}/snap and replacing it with @{HOME}/.snap wouldn't solve the problem? What containerization would be broken if you found and changed every reference to the snap folder?

luarocks (luarocks) wrote :

+1. Purged snap until it's fixed!

Robert Kujawa (kujaw) wrote :

Also had to purge it, since this bug has a lot of people affected and looks like maintainers don't give a freak. Luckily, there are other easier and unaggresive ways to install software I need without cluttering the system.

Thiago Madureira Braga (thmb) wrote :

Purged snap until it's fixed! Snap seems to be a great idea but I don't want it trash my home.

Zygmunt Krynicki (zyga) wrote :

I am working on a bit of refactoring of of the snapd execution layer that will culminate in the ability to fix this bug. I'm very much interested in fixing it.

For everyone interested: it is not easy to just move the directory or to make it configurable. The technical reasons are pretty long and complex so I will skip listing them here.

The work I'm doing will allow us to explore the following:

- move the $HOME/snap directory to a hidden directory (e.g. to $HOME/.snap)
- preserve compatibility with all existing snap packages
- allow us to create a view of $HOME/.snap that is optional, can be provided under any name (e.g. $HOME/Snaps or "$HOME/Fancy Futuristic Packages", and one that has much more interesting contents than $HOME/snap does today. Lastly it will allow us to engage with the developers to shape how they present snap files to users.

I'm not ready to commit to any timelines yet. I just want to let everyone know this is something we are working towards.

Michael Walz (serpedon) wrote :

+1 for fixing this

In the meantime, I purged everything snap-related except pdftk which I use occasionally. For pdftk, I wrote a small wrapper which (except one symlink) removes the otherwise empty folder hierarchy $HOME/snap automatically after using pdftk.

Niko Wicaksono (wicaksono) wrote :

+1 flatpak is better for this time.

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

Duplicates of this bug

Other bug subscribers