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

Bug #1575053 reported by John Wang
This bug affects 1252 people
Affects Status Importance Assigned to Milestone
snapd
Confirmed
High
Zygmunt Krynicki
snapd (Arch Linux)
New
Undecided
Unassigned
snapd (Debian)
New
Undecided
Unassigned
snapd (Ubuntu)
Confirmed
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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in snapd (Ubuntu):
status: New → Confirmed
Michael Vogt (mvo)
Changed in snapd (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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

Revision history for this message
Terry L. Triplett (terry-triplett) wrote :

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.

Revision history for this message
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).

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1575053] Re: User data directory should conform to XDG Base Directory Specification

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

Revision history for this message
Jamie Strandboge (jdstrand) wrote : Re: User data directory should conform to XDG Base Directory Specification

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

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1575053] Re: User data directory should conform to XDG Base Directory Specification

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

Revision history for this message
GizmoChicken (gizmochicken) wrote : Re: User data directory should conform to XDG Base Directory Specification

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
Revision history for this message
GizmoChicken (gizmochicken) wrote : Re: Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to "$HOME/.local/share/snap" in accordance with the XDG spec)

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
Revision history for this message
Stego (stegomon) wrote :

Much wanted!

Revision history for this message
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?

Revision history for this message
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).

Revision history for this message
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"?

Revision history for this message
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
Revision history for this message
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)

Revision history for this message
David (lofidevops) 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

Revision history for this message
Tom (tom-lorinthe) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 ;)

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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).

Revision history for this message
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.

Revision history for this message
aaronfranke (arnfranke) wrote :

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

Revision history for this message
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.

Revision history for this message
machrider (machrider) wrote :

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

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Seif Allah Tarhouni (saksow) wrote :

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

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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)
no longer affects: snappy
Jeremy Bicha (jbicha)
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)
Changed in snapd (Fedora):
status: New → Invalid
no longer affects: snapd (Fedora)
Zygmunt Krynicki (zyga)
Changed in snapd:
importance: Wishlist → High
assignee: nobody → Zygmunt Krynicki (zyga)
245 comments hidden view all 325 comments
Revision history for this message
praesepe (praesepe) wrote :

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

Revision history for this message
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).

Revision history for this message
Tobi Schäfer (interface) wrote :

:thumbs_down:

1 comments hidden view all 325 comments
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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. :)

Revision history for this message
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.

Revision history for this message
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. :)

Revision history for this message
Chris Vanden Berghe (chrisvdb) wrote :

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)
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)
Changed in snapd (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
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.

Revision history for this message
Sebastian Makowiecki (soocki) wrote :

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

Revision history for this message
Sergei Veselovskii (whitebearspirit) wrote :

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

Revision history for this message
Roberto Lobo (rhlobo+launchpad) wrote :

@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

information type: Public → Public Security
information type: Public Security → Public
xfwangbjtu (xfwangbjtu)
Changed in snapd (Ubuntu):
assignee: nobody → xfwangbjtu (xfwangbjtu)
assignee: xfwangbjtu (xfwangbjtu) → nobody
Revision history for this message
Nagy Gergely (nagygeri11) wrote :

I humbly want to express my disbelief in that such a seemingly simple problem: hiding Snap's own directory from the $HOME, which seems as easy as renaming $HOME/snapd to $HOME/.snapd, has been going on for 5 years, with a number of proposals and promises arising (as early as in [#18](https://bugs.launchpad.net/snapd/+bug/1575053/comments/18) in 2017) and failing to deliver. Especially as this is the top bug report.

In 2017 it was pointed out that a fix should happen ASAP before Snap rolls out, and I agree - I guess that shot was already missed by long.

I fail to understand why Snap's data folder was visibly placed in $HOME in the first place, when it was a widely accepted consensus that data folders of specific apps must be hidden somehow. This really should be fixed promptly, it's ugly.

In any case, to me it seems to highlight some fundamental design problem that we have a hard-coded string in the codebase, that seems to be such a huge trouble to modify by even as little as adding a "." to it.

Revision history for this message
Ivan (ivanperez-nfm) wrote :

I would not have that big a problem if Ubuntu had not made it the preferred way of installing and packaging apps now.

It highlights more fundamental issues with the design of snap, with the management, and with the way that it was included and promoted. And this is just one issue that is relatively simple. But if it had been a serious issue that affected packages, would it also have taken more than 5 years to address?

Is there a way to escalate this to the team at Canonical that made the decision to bring snap in in the first place?

Revision history for this message
Nathan Hunt (nathanhunt) wrote :

I finally resorted to the uninstall snap workaround. Annoying users and being intrusive is a solid way to ensure the success of a package you're responsible for.

Revision history for this message
Karl Ljungkvist (k-ljungkvist) wrote :

Seeing how this has been treated for 4.5 years makes this seem like a pretty dysfunctional project. Please have mercy on your poor users and fix this.

Revision history for this message
Robin (tezaro) wrote :

To Snap and Ubuntu developers, here is a concrete example of why this is important and so many people are annoyed.

Imagine a user likes to back up their home directory. (Imagine that! Crazy stuff!)

The user will likely exclude hidden files from the backup, so as to avoid filling their storage with useless cruft, and maybe to avoid hitting storage or bandwidth limits (which can result in unexpected bills).

By squatting the user's home directory, uninvited, Snap screws everything up. The user will need to hard-code an exception into the backup script. For one package. All the other packages respect the XDG rules. All of them except Snap.

To Ubuntu developers in particular: by switching APT packages to Snap (Chromium for instance) and thereby causing an `apt install` to pull in Snap unrequested, you are breaking people's home directories, their scripts, their backup solutions, and the rules.

Revision history for this message
Danny Trunk (dtrunk90) wrote :

After 5 years there's still no fix. This is so annoying. I'm now getting rid of all snap packages and installing deb variants instead. Finally I'll purge snap and if these weird decisions keep on going I'll also move to another distro. Common Canonical. Seriously?

Revision history for this message
Alex Murray (alexmurray) wrote :

This is actively being worked on - for those interested you can follow the progress in https://github.com/snapcore/snapd/pull/10836

Revision history for this message
Dimitri Papadopoulos (dimitri-papadopoulos) wrote :

Note that .snap is also the default location of snapshots of the Ceph file system (https://github.com/ceph/ceph). It's a hidden (not visible during a directory listing) directory available in each directory of a mounted Ceph file system. See:
https://docs.ceph.com/en/latest/dev/cephfs-snapshots/

So if $HOME lives on a Ceph file system, ~/.snap (associated to snap) will clash with ~/.snap (associated to Ceph). A different location is needed, such as ~/.congif/snap/config for example.

Revision history for this message
Avamander (avamander) wrote :

@dimitri-papadopoulos

If there's a high likelihood that ceph will be used on a desktop distribution then its choice of snapshot directory has been incorrect in two ways. The way forward would be to not ignore conventions designed to avoid such issues :)

Revision history for this message
Luke (lukeweller-deactivatedaccount) wrote :

Is anyone from Canonical actually working on this bug? And why tf is this still considered a "Wishlist" item after 1200 user reports and hundreds of comments?

Revision history for this message
Maciej Borzecki (maciek-borzecki) wrote :
Revision history for this message
Luke (lukeweller-deactivatedaccount) wrote :

@Maciej Borzecki So that's it? There's an experimental setting I can use to manually move my ~snap folder. No documentation to go with it? No plans to actually implement this feature for anyone who isn't extremely tech literate?

That solution is less helpful than the ~/.hidden workaround that the userbase figured out years ago

Revision history for this message
Maciej Borzecki (maciek-borzecki) wrote :

@lukeweller you probably guessed this is not part of any release yet. Documentation will be there in due time. In the meantime you're welcome to contribute to the discussion in the forum or grab snapd from edge and try it out yourself.

Revision history for this message
Luke (lukeweller-deactivatedaccount) wrote :

@Maciej Borzecki I'll believe that when I see it.

This thread is a five-year history of users requesting a fix and the dev team responding that the users are stupid and it's not really a big problem.

Why should we believe you that this will ever be fixed, let alone documented?

Revision history for this message
Wolfgang (wolfgang-v) wrote :

I was so excited to see the link with more info on what the migration will look like: https://forum.snapcraft.io/t/experimental-flag-for-hiding-snap/28509/21

...only to find out that the end goal is to introduce a new ~/Snap directory (that - if I understand correctly - again cannot be changed by the user).

Prepare for another 5 years of pleading with the devs about the same issue again. Even before the old issue even was resolved.

Revision history for this message
Ivan (ivanperez-nfm) wrote :

I would not care anymore were it not for the fact that snap is becoming the default. We will have a less and less usable system if we just remove snap.

Can we not just request to the Ubuntu team that snap be removed from the default installation, and that no package should be made available only via Snap? (for example, currently, chromium is only available via snap).

Revision history for this message
Ivan (ivanperez-nfm) wrote :

Given that this is affecting so many people: I've opened a request against Ubuntu-meta so that Snap stops being recommended by default and we make sure no packages provide snap-based installation only:

https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965535

Feel free to comment there.

Revision history for this message
Forest (foresto) wrote :

Thank you, Ivan. I have add my "affects me" status and a comment there.

Revision history for this message
Alex Cabal (acabal) wrote (last edit ):

Before 22.04 I was able to just uninstall snapd to remove ~/snap, and that was fine.

But now that Firefox is being delivered as only a Snap in 22.04, I'm essentially being strong-armed into using snaps, because Firefox is probably the most critical piece of software on my system and I cannot work without it.

Given this new situation, the ~/snap folder has gone from an annoyance that can be fixed by uninstalling snapd, to an intolerable situation that I will literally switch distros over. It makes me irrationally angry to have a piece of low-level systems software that I rarely want to interact with park its junk right in the middle of $HOME, the place where I organize my personal documents. Why not make ~/dconf or ~/pam while we're at it?

Please don't make me leave Ubuntu in 22.04 - just move the damn folder to ~/.snap or even better ~/.local/snap already.

A forums thread was mentioned earlier in this bug report where the snap maintainers change ~/snap to ~/.snap ... BUT THEN THEY GO ON TO CREATE ~/Snap! Come on!!

Revision history for this message
Forest (foresto) wrote :

The effectively forced use of Snap is what finally drove me to abandon Ubuntu. This issue played a part in that.

To be clear, I am in favor of app isolation on desktop linux, and I find container-based packaging useful in certain situations. However, the Snap project has demonstrated over and over again that the people driving it fail to grasp important issues like user agency and open systems. Like Alex, I find the result intolerable. Being rid of it was worth the temporary pain of switching distros.

So long, Ubuntu, and thanks for all the fish.

Revision history for this message
yannek (yannek-deactivatedaccount) wrote :

I can only echo acabal, foresto and a lot of the above comments. The technical merit of snap is not the point. But cluttering the homedir as a default _and_ offering no way around is not acceptable from any application. Hidden folders do exist for a reason, /var exists for a reason.

In the end, this gave the impulse to finally move over to Debian. After more than fifteen years of Ubuntu. I fear that you're destroying a lot of well earned goodwill. :-(

Please fix this for the sake of Ubuntu.

Revision history for this message
Eric Mazoob (zoob) wrote :

I just upgraded to 22.04, and was unpleasantly surprised to see ~/snap as a new directory in HOME. If there is no solution for this issue I will be switching back to Fedora.

Revision history for this message
Kevin Dong (kevin-dong-nai-jia) wrote (last edit ):

For someone who is still struggling with this,
https://forum.snapcraft.io/t/experimental-flag-for-hiding-snap/28509
may prevent snap from storing data in ~/snap folder.

However, it seems that
sudo snap set system experimental.hidden-snap-folder=true
works and puts data in ~/.snap/data, but snap still creates an empty ~/snap on app startups.

Fortunately, we could always leverage crond
* * * * * rmdir ~/snap
to remove the directory when it is empty though. ;-)

Revision history for this message
Zingam (registrirayme) wrote :

Just add an UI option to hide this folder from the system.

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

Duplicates of this bug

Other bug subscribers