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

Bug #1575053 reported by John Wang on 2016-04-26
This bug affects 1134 people
Affects Status Importance Assigned to Milestone
snapd
High
Zygmunt Krynicki
snapd (Arch Linux)
New
Undecided
Unassigned
snapd (Ubuntu)
Wishlist
Unassigned

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".

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[2] https://wiki.debian.org/XDGBaseDirectorySpecification

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

snap

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: https://askubuntu.com/questions/885076/how-can-i-change-the-location-of-the-default-snap-folder

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 :

@Terry

"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."

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.

Mark

"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.

Mark

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 https://github.com/flatpak/flatpak/wiki/Filesystem 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 https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/39?u=chipaca and possibly https://forum.snapcraft.io/t/when-are-epochs-stepped-upgrades-coming/758?u=chipaca 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 ...

from https://wiki.ubuntu.com/Bugs/Importance

- 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 :)

Source: https://askubuntu.com/a/882964/7146

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)

...so 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 https://github.com/flatpak/flatpak/wiki/Filesystem 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 (navoytak) on 2019-12-20
Changed in snapd (Fedora):
status: New → Invalid
no longer affects: snapd (Fedora)
Zygmunt Krynicki (zyga) on 2020-04-30
Changed in snapd:
importance: Wishlist → High
assignee: nobody → Zygmunt Krynicki (zyga)
221 comments hidden view all 301 comments
Avamander (avamander) wrote :

> In addition the ~/snap directory is very explicitly, and non-trivially baked into apparmor profiles that are currently global to the system.

And whose fault is that? Should've thought about it sooner.

> Lastly .config and .local and .cache are just top-level directories with absolutely no structure inside.

And whose fault is that? You're absolutely free to create the structure you want, you've already mangled it, what does it matter now.

Gustavo Niemeyer (niemeyer) wrote :

Zygmunt, let's stick to the design and the spec only. Speculation or subjective remarks do not help the conversation.

Avamander, your personal notion of fault attribution won't help you or anyone else.

There's a lot of people here. Let's please preserve this thread relevant and respectful.

Jamie Strandboge (jdstrand) wrote :

> In addition the ~/snap directory is very explicitly, and non-trivially baked into apparmor profiles that are currently global to the system. This setting can vary per user.

We have mechanisms in AppArmor to help with alternate locations for things (there is the home tunable and we could add new ones for 'snap' or anything we want). This would not be difficult to implement policy-wise.

As mentioned several times in this thread, the issues are bigger than that. To Gustavo's point, there is a design and a specification for addressing this bug in a nice way, and it is on the current roadmap. This bug will be fixed.

GizmoChicken (gizmochicken) wrote :

I was an early and vocal critic of the "$HOME/snap" directory who:

(a) complained about this issue in numerous comments, including comment #14 (posted 2017-04-16), comment #15 (posted 2017-05-20), comment #19 (posted 2017-07-12), and comment #32 (posted 2017-10-22);

(b) reverted the status of this issue back to "Confirmed" (after another moved it to “Opinion”) on 2018-02-25; and

(c) edited the summary to succinctly read "Please move the "$HOME/snap" directory to a less obtrusive location" on 2018-02-25.

As an early and vocal critic of the "$HOME/snap" directory, I humbly and respectfully ask the following favor of those who continue to post here complaining about this bug:

STOP IT!

The devs have heard us, they are diligently working to solve this issue, and they will provide a solution as soon as practicable.

Thank you for your understanding. :)

David Norris (dvnrrs) wrote :

You say "as soon as practicable" but this bug is over 4 YEARS old now. I think the frustration from the users is completely understandable and justified. It's by far the hottest issue on the list but the developers continue to waffle. Not that I think one more post is going to change anything, except to increase the visibility of the fact that this is such a ridiculously mismanaged and misprioritized project. I see that as a good thing.

If the periodic emails annoy you, you can always un-watch the issue.

Gustavo Niemeyer (niemeyer) wrote :

> a ridiculously mismanaged and misprioritized project

So you create an account just to come here say that? Indeed we have different a notion of priorities and time allocation, David.

Avamander (avamander) wrote :

So are we now shaming people because that they are personally affected by a bug for years, that decided to participate in the community?

I suspect the reaction would be a lot milder without all this thinly-veiled condescension constantly thrown at people here. I'm personally appalled.

Gustavo Niemeyer (niemeyer) wrote :

This is a place for respectful collaboration about the project and the issue at hand. People in the community are most welcome to participate and help, and many have done exactly that.

Insults and blaming are not welcome here or anywhere else in this community, though, no matter how much you care about it. If we're unable to talk about the actual issue here due to this kind of behavior, we'll lock it down and move the conversation elsewhere.

David Norris (dvnrrs) wrote :

I already had an account, it's totally fine (see comments #184 and #192).

I'm not individuality insulting anyone and I'm also not trying to be rude. But come on, 4 years? If the developers are going to drag their feet that long - an outright eternity in software development terms - on such a high profile issue, even after such a strong community response, then in my professional opinion they should not be at all surprised when people find the project mismanaged.

Purging snapd is literally the first thing I do after any new Ubuntu installs. I consider it bloatware and just shy of malware. I wish I didn't have to.

Gustavo Niemeyer (niemeyer) wrote :

The way we select priorities for the project every single cycle for years is having several stakeholders (that's more than a dozen people, covering community, customers, development groups, etc) with several different perspectives in a room after having followed a process of funneling requirements from these same groups over several weeks. We then have a long discussion to agree on what are the most important priorities for the project for the coming cycle, and then a fantastic development team works on these features for the next several months, often doing minor adjustments to the roadmap as the cycle progresses and we have new factors coming in.

I realize that sitting here in a bug for 4 years waiting for your pet peeve to be fixed may be unsettling and frustrating, but hopefully the interactions from the team in the history above are good data to show that we've been around all along and did intend to improve things eventually. Not in your preferred timeline, unfortunately, but we have many more issues and voices to pay attention to.

That's why you see https://snapcraft.io/store and the snap project and community being what they are today. Because we do care, and we do follow a process that is not just hand-picking issues arbitrarily.

I'm sorry that you prefer to remove the application and vote yourself out of this community, but this is a freedom we also appreciate around here. We're glad you can make yourself comfortable with other tools. We'll stay here, improving things meanwhile.

Avamander (avamander) wrote :

> Not in your preferred timeline, unfortunately, but we have many more issues and voices to pay attention to.

How do you have "many more" voices to pay attention to? 1018 people have marked this issue as it affects them, if anything, you have *many fewer* voices to listen to elsewhere.

> waiting for your pet peeve to be fixed may be unsettling and frustrating
> We'll stay here, improving things meanwhile.

This is exactly the thin-veiled condescension I mentioned earlier.

"I'm sorry you chose to feel insulted or blamed by earlier comments by dvnrrs."

Gustavo Niemeyer (niemeyer) wrote :

> How do you have "many more" voices to pay attention to? 1018 people have marked

We have millions of users, Avamander.

> "I'm sorry you chose to feel insulted

Your words.

Now I'll stop here and hope that we can go back to being productive on this issue. Failing that, we'll lock this thread up so we can all focus on the project development.

Nabil Anam (nabil-anam) wrote :

This needs to go

2 comments hidden view all 301 comments

For whom does not care about multi users and backward compatibility, this is actually quite straightforward to change the snap directory from '$HOME/snap' to '$HOME/.snap'. Changing the hard-coded path and the AppArmor rule is fairly enough for release 2.46:

diff --git a/dirs/dirs.go b/dirs/dirs.go
index 2986ef371a..ea37ad195e 100644
--- a/dirs/dirs.go
+++ b/dirs/dirs.go
@@ -136 +136 @@ const (
- UserHomeSnapDir = "snap"
+ UserHomeSnapDir = ".snap"
diff --git a/cmd/snap-confine/snap-confine.apparmor.in b/cmd/snap-confine/snap-confine.apparmor.in
index 8b53423ca0..cde82139b5 100644
--- a/cmd/snap-confine/snap-confine.apparmor.in
+++ b/cmd/snap-confine/snap-confine.apparmor.in
@@ -346 +346 @@
- @{HOME}/snap/{,*/,*/*/} rw,
+ @{HOME}/.snap/{,*/,*/*/} rw,

I was doing a cleanup of my $HOME directory, and sadly I found this "snap" dir, this made me follow through and find this open issue... open for MORE than FOUR years already... is this fixable? Because if it's fixable and this much time has happened I can't help but to feel contempt for the snap project... but if it's IMPOSSIBLE to fix then I feel pity for snap... but anyways, my views on this have no relevance, I'm just a single user, and I only have three applications installed with snap: Audacity, VLC, and Chromium. I was able to build Audacity from source, and I'm sure that there is a way to use VLC and Chromium without Snap, there has to be a way, so even if I purge snap, I'm just a random person of the world, it's not going to change anything, just one more of the many affected by this design that shouldn't have even existed in the first place. So, why even write? So the people at the Snap project can see that they are getting uninstalled BECAUSE OF THIS ISSUE.

GizmoChicken (gizmochicken) wrote :

@polirecyliente,

Please allow me to reiterate what I wrote in post #265 of this thread:

>I was an early and vocal critic of the "$HOME/snap" directory who:
>
>(a) complained about this issue in numerous comments, including comment #14 (posted 2017-04-16), >comment #15 (posted 2017-05-20), comment #19 (posted 2017-07-12), and comment #32 (posted >2017-10-22);
>
>(b) reverted the status of this issue back to "Confirmed" (after another moved it to “Opinion”) >on 2018-02-25; and
>
>(c) edited the summary to succinctly read "Please move the "$HOME/snap" directory to a less >obtrusive location" on 2018-02-25.
>
>As an early and vocal critic of the "$HOME/snap" directory, I humbly and respectfully ask the >following favor of those who continue to post here complaining about this bug:
>
>STOP IT!
>
>The devs have heard us, they are diligently working to solve this issue, and they will provide a >solution as soon as practicable.
>
>Thank you for your understanding. :)
>

tl;dl:

STOP IT!

The devs have heard us, they are diligently working to solve this issue, and they will provide a solution as soon as practicable.

Thank you for your understanding. :)

iBART (mogio) wrote :

It is insane... it affects me too!

Mr Aaron J Michaux (amichaux) wrote :

I came up with a convenient solution. I added the following to my crontab:

* * * * * rm -rf /home/amichaux/snap

Works like a charm.

Facundo Quiroga (facundoq) wrote :

I really appreciate the effort put into snapd. However, as a fellow software developer, I honestly fail to understand how an issue that's been going on for 4 years and has the most heat of all issues (https://bugs.launchpad.net/ubuntu/+source/snapd/+bugs?orderby=-heat&start=0), that depends on **being able to configure a base folder for snaps** requires a design document after 4 years of discussion. Specially when as mentioned before, the linux ecosystem already has defaults for this (ie, .local/, etc), or maybe a SNAPS_HOME env var?. I'm really curious as to how the current design precludes a simple fix. Any suggested link to read about this?

Ash Holland (sersorrel) wrote :

I would suggest you read through the past comments on this issue, and the design document you mention. For example, "put things in the XDG directories (~/.local, ~/.cache, ~/.config)" has been suggested many times; it's explained earlier in the comments here (e.g. comment #30) why that wouldn't work, and the same applies to an environment variable like $SNAPS_HOME.

Tichun (tichun) wrote :

Reproducing this critical problem in 20.04.1 LTS.

praesepe (praesepe) wrote :

20.10
/home/user/snap still there...
I have a bad impression that he will never leave

Wolfgang (wolfgang-v) wrote :

My hopes are still up - see comment #259 for some more information about the process: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053/comments/259

I really hope 21.04 still is reachable. Not sure where to find the public design document though (or if it even exists yet).

Tobi Schäfer (interface) wrote :

:thumbs_down:

1 comments hidden view all 301 comments
Thomas Wehmöller (mordragt) wrote :

From a high level view it seems like the project is far from being usable in mission critical systems if there are so many other problems that are prioritized over this community outrage. But maybe i am wrong and user feedback is just not valued here.

Jean (jean-miguel) wrote :

We just updated all of our Ubuntu installations to 20.04 and first everything seems very smooth. But after installing chromium-browser the annoyances began. After slow program starts we realized it's no real deb package anymore and it silently installs a snap! Then users realized the intrusive /home/user/snap folder and asked to move it out of their home directory.

My research took me to this snapd bug and I can't believe this is debated for MORE THAN FOUR YEARS! And there is still no config option available. Holy shit! How is that possible?

This snap thing is not ready for production! All snap applications need more than 10 seconds to start on fast SDD systems and bring this intrusive snap folder in the home directory. I can't belive that.

Seems Ubuntu is going the Windows 10 way and annoying the user more and more and ships shiny objects which try so solve problems that doesn't even exist. Now we have to uninstall all this snap stuff again and search for the corresponding deb packages Ubuntu has ditched.

We really hope Ubuntu will notice they have gone astray and the next LTS version will rely on 100% deb repos again. Otherwise lot's of people will make a switch to other snap-free distros.

Kyan Jiao (kyanj) wrote :

This is my first time using snap, and i realized there's a 'snap' folder in my $HOME. Google redirected me here. It's really a surprise that this is still not fixed in 4.5 years.

We don't care those internal stuff. Please just get rid of this folder, no more excuses. There are millions of linux tools, and I really don't understand why snap is special and insisting on creating a visible folder in $HOME.

Wolfgang (wolfgang-v) wrote :

@jean-miguel and anyone else affected: Please report your feedback to Ubuntu customer support too, so that they can draw their own conclusion on how their product decisions affect their user base.

GizmoChicken (gizmochicken) wrote :

Wolfgang (wolfgang-v) wrote:

>@jean-miguel and anyone else affected: Please report your feedback to Ubuntu customer support too, so that they can draw their own conclusion on how their product decisions affect their user base.

Wolfgang, you forgot to suggest that all dissatisfied users should DEMAND a FULL REFUND of the licensing fees charged by Canonical to use their FREE software. :)

Wolfgang (wolfgang-v) wrote :

GizmoChicken, I apologize for my post. Wanted to delete it but cannot figure out how.

Was just so frustrated in the moment about the non-communication about progress and that Canonical decided to push snap in the current state, even though they participated from the beginning in this thread and are fully aware that they are putting a visible directory right in the user home directory that cannot be moved/renamed.

I try to be hopeful, but sometimes it is getting so difficult. Was so hyped about comment #259. Maybe I am just not familiar enough with the process. Do you know where this design document was published? Just anxious that there is no progress and it was just an empty announcement.

GizmoChicken (gizmochicken) wrote :

@Wolfgang: No worries. And as an early and vocal critic of the "$HOME/snap" directory (see post #14, for example), I share your frustration. But I've come to realize that devs truly want to, and are working to, resolve the issue. We (the users of this FREE software) just need to be patient. And for those of us who can't be patient, removing snapd remains an option. As for me, I'll keep snapd for now, and continue to wait patiently for an eventual fix. :)

Was wondering if this is still scheduled for 21.04 as suggested in the below comment by @niemeyer...

> From recent conversations with the team, the approach has been discussed and we have
> an agreement on it, we should now see a design document made public in the next few
> weeks (september still, hopefully), which means an implementation available in the
> next few months. So we'll see it as part of the snapd release that will be in 21.04.

a59ff5 (a59ff5a59ff5) on 2021-03-29
Changed in snapd:
status: Confirmed → Fix Released
Changed in snapd (Ubuntu):
status: Confirmed → Fix Released
Changed in snapd:
status: Fix Released → Confirmed
Colin Watson (cjwatson) on 2021-03-29
Changed in snapd (Ubuntu):
status: Fix Released → Confirmed
Sebastian Makowiecki (soocki) wrote :

Hello kind pple, pretty please move this dir from the central home location, it does not belong there! Thank you kindly.

Sebastian Makowiecki (soocki) wrote :

Ah my apologies was it fixed? Am I still running an old version? Thank you thank you thank you!

Hey guys what about the fix?
Placing a directory that was meant to be hidden to user's home dir is uncool.

@Gustavo and dev team

In #259 it was said that an approach has been discussed and agreement uppon. I understand that on 2021-03-29 a fix was confirmed, although I could not find anything on the matter (including the design document).

I am running snap/snapd 2-50 (full system, fresh install) and a snap dir was created here. I am not demanding things be my way, but I am putting huge effort to build my system from ground up, eading/learning/configuring everything as much as possible, and have no clue how this matter evolved (far more clueless than an blind person on a wild west shooting).

This thread has been quite inactive lately and I would be gratefull if someone could clarify if something was changed/fixed (then I know something is missconfigured on my side).

I undestand that better xdg portal integration was released, bit as I am running arch + xmonad I dont have that setup (has lots of deps including gnome-desktop). Does that has something to do with that?

Thanks in advance

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

Duplicates of this bug

Other bug subscribers