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

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

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.

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.

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.

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.

@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).

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

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.

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

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.

Much wanted!

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?

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

@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"?

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

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)

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

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

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.

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.

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

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.

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

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

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.

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

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

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

+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

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.

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

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

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

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.

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.

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

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!!

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.

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.

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.

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. ;-)

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

echo snap >> ~/.hidden

Might be a default configuration for all new users if included in /etc/skel ?

Now that we are forced to use snap for Firefox, this should really be fixed.

I was also very unpleasantly surprised to have snap appear in my home directory. The workaround with .hidden is not real a solution.

I had avoided using snap in previous Ubuntu versions but with the Firefox change this is getting harder.

I'd like to heartily agree with this bug six years after it was first filed (currently in Kubuntuu 22.04 LTS). This is a visible directory in the Home directory and it's there by default along with all the other default directories. Since it doesn't follow the naming convention of having an upper-case first letter, it not only looks silly, but also interferes with case-sensitive sorting done by some programs. I would be fine with it either being given an upper-case first letter or being made hidden in the event that we're not intended to manually interact with it. Please fix this.

What truly bothers me about this is the following:

1. Cluttering the home directory is a disorganized practice.
2. The purpose of package management systems like snap is to organize software.
3. Therefore snap violates its own purpose by creating disorganization while it organizes.
   The snap system is fundamentally disorganized by design.

I would compare it to a food pantry that throws away food... a police officer who drives recklessly... a dishwasher that cleans the dishes but throws food particles onto the floor... I could go on and on with ridiculous examples of things that do the opposite of what they are supposed to do.

It belongs under ~/.config or ~/.local

Reported in 2016! This is incompetence beyond comprehension, you're giving the Democrats some solid competition... even Sleepy Joe's quicker than you lot!

I have never seen such arrogant software and developers. This is a foolish act. I will uninstall snap until this problem is solved. Or, I think I can try to abandon Ubuntu. Debian or Fedora may be a better choice.

It's been at least a few years since I've last checked on this issue. When initially exploring snap as a solution for application packaging, I discovered that the snap developers had decided to address a technical / security related issue by implementing a "hard coded" solution - one which, though maybe convenient for snap developers, goes against popular (an understatement) both formal and informal standards (mentioned in many previous comments). With this being the case, and since that original date a few years back, I have not developed apps in or utilized existing apps using snap and have instead used other solutions. Id est, my development and utilization behavior is as though snap does not exist. Snap will continue not to exist as an option (for my uses) until (at least) this issue has been adequately resolved.

As a side note, others have mentioned the "arrogance" involved in this decision. I've encountered plenty of what I would characterize as "questionable" decisions by development teams, however I have to say that this one is certainly "outstanding", not at all in a good way. I don't have the time or inclination to probe further into why hard coding a directory location is a feasible solution to a security issue, but fortunately snap has enough competition that I can effectively forget that snap exists for years at a time without either feeling like I'm missing anything or having the lack of it impact my productivity.

Not that alternatives to snap are by any means perfect, but thank goodness for the competition.

Cheers all =)

cd ~
echo snap >> ~/.hidden

Done, snap folder is hidden as any other folders and files related to user's setting, parameters and config's.

Seems to have no effect at all on ls command.

I am amazed how long this bug has been open; it is one of the major reasons why I entirely purge snap from my system when I install Ubuntu.

I moved from Windows to Ubuntu for freedom of choice. The bug described here removes my freedom to organize my files how I want to. It is making me question whether I continue with Ubuntu in the future or move to a different Linux flavor.

What is being done about this!? It's been 4 freaking years!!

Why is this still cluttering my home directory? Please just move it inside .config

A little user update...

I'm still with Ubuntu 20.04, I completely purged snapd and my Firefox is installed as .deb. Still, every now and then Firefox creates ~/snap/firefox, meaning that the thing is now becoming somehow hardcoded or at least impossible to completely get rid of.

I recently became less annoyed about this issue, I think I understand better what the real topic is. We're complaining about the usage of Linux $HOME but this is not the old Linux anymore, it's more Android or iOS. Nobody opens bug complaining about directory structure in Android, do you? Nobody cares how big the Android Apps are, or where exactly they are installed, as long as they can access the camera and upload to Instagram. Nobody complains about the output of df under Android. And IMHO Ubuntu has taken this path, and if you (and I) have the 'ls' output of $HOME as priority then switch to standard Linux.

I don't consider this a bug anymore, it's a design feature of the new way of distributing software, and I think it will never be fixed because Snap is not about having a nice $HOME folder nor respecting the UNIX folder conventions from 1970. The bug is in our expectations.

I can understand your reasoning, I surely don't care about folder layout on my Android device.
But I am also fully aware that my Android device is essentially operated by Google.
They do whatever they want with the device, and I'm merely a consumer that gets to use the browser and a few other apps.
My computer is different. It's MY device. I get to make the rules. This is what free software was all about in the first place.
Since Firefox got converted to a snap, it takes ages to load on my girlfriends old laptop.
Sometimes, it doesn't start at all and just gives a black window so you have to close and re-open.
And in my dayjob, I had big problems with the chromium snap and Gnome Window management when trying to use the kiosk mode to make a web-app.

I would like to get rid of snaps, but I can't since Canonical has decided for me.
And while this bug is about a stupid folder that won't go away, for many of us it's about Canonical not having our best interests at heart any more.
That's why I'm leaving the Canonical ecosystem. And I'm taking my employer's infrastructure with me.

There's still on going work, but you're certainly right about moving on. As much as I feel bad for having this buh open for so long, we're a small team that haven't been sitting on our hands and don't welcome that kind of disrespect here, no matter how much you'd prefer for us to have done something else with the time we have.

Well, maybe people are somewhat upset because snap is not offered as an option, but enforced by having important tools like Firefox and Chrome-Browser as a snap only.

So while respecting your work and the limited time and small team on one hand, it is on the other hand lack of respect for the work and limited time of all those people out there using ubuntu, by enforcing the rather raw product of a small team with limited time.

I'm not going to jump into this discussion about the name of ~/snap, although I admit, I find it disturbing too. I also had a long list of problems and wasted time to debug problems with snap due to insufficient documentation and questionable design decisions.

I remember pretty well the time when I had the problem that snapd caused me costs and problems, because it self-actingly downloaded mega- and gigabytes while refreshing snaps although I was an a really thin and metered expensive Internet connection. The ignorant answer from the team was, that they do want it that way, and don't care about other peoples situation. Or just trying to figure out what the hell snap is doing at runtime, because things were not working, but no documentation available about what is going on. Cost me a lot of time.

So I do consider it as inappropriate, if you demand respect for your team, while on the same time your design decisions do not pay any respect to Ubuntu users, and do not give them a choice whether to use snap or not. If your work is till going on and your time is limited, then maybe it was just too early to enforce the use of snapd.

Respect is not a one-way street. What goes around comes around.

I said nothing about respecting my work. We have a base level code of conduct, and people in this community are expected to respect each other, whether there's agreement or not. Failing that, nothing else makes sense and indeed you're better off moving out so other people can talk and help each other.

I have to agree with Hadmut that if the team is so small and busy with other things that it hasn't been able to address a high-importance bug that's causing a disturbance for users in nearly 7 years, then it seems that the decision to make it a default was premature. Is there any way the team can back-pedal on that decision until the team is more prepared?

Six years later and this is still an issue.

Can we please get an option to remove Snaps on install, or even prior to install the way a user can select to use different filesystems when installing? It makes no sense for such half-baked solutions to be pushed as hard as this seems to be. It's been what? Six? Seven years since post #11? When Mark Shuttleworth cannot get something fixed in Mark Shuttleworth's distro you know there is a problem...

sudo snap set system experimental.hidden-snap-folder=true

I had to move some folders from ~/snap to ~/.snap/data manually, rather than wait for a new version of those snaps in order for a refresh to migrate them. But after uninstall / reinstall of the ones I moved manually, I now no longer have a ~/snap directory.

I don't think there's any bug here. This is working as intended and there's a working alternative for folks who don't want ~/snap.

Another "me too" after I installed snap and then suddenly "WTF is there"!!? ;-P
Amazed to see that it took 6 years to have a configuration option allowing to put it where it should have been in the very first place. Yes, Apparmor profiles could be a reason why this is not easily configurable, but why not use ~/.snap or even better, ~/.config/snap from day 0?

Anyways, not only complaining: a big thanks to the developers for the nice tool! :-D

Love snaps but putting a "Snap" folder, hidden or not, inside /home/$USER is really annoying. Please follow XDG and put the folder inside .local or .cache or other subdirs that already exist in home folder.

Thanks

I do agree with #350.

Is there any chance that 'system experimental.hidden-snap-folder=true' will become the default for 24.04 LTS?

Please move or atleast .hide the folder.

Agree wholeheartedly with #89 and #350 (except for the part in #350 about loving snaps--they are a major reason why people are leaving Ubuntu, of course; YMMV).

It is annoying that snaps have been designed broken in this way; it is even more annoying that this bug has now remained unfixed for almost eight years.

I've been a user of Ubuntu ever since Warty Warthog, when Canonical used to ship the installation CD worldwide for free. Now I'm officially moving to Fedora due Canonical trying to shove Snap down our throats.
Congratulations on destroying what could potentially be the Linux Distro To Rule Them All by trying to solve a problem that never really existed with a terrible tool.

Adding my voice to this. I will continue to run `sudo apt autoremove --purge snapd` as the first command on every fresh installation of Ubuntu until they no longer live in ~/snap. ~/.snap is a perfectly acceptable alternative, ~/.local/snap is even better.

I will not use snaps - and if that breaks things, that's fine. As far as I am concerned, those breakages are a bug. Any features lacking after the removal simply make Ubuntu inferior to other projects with less fragmented package systems - and if it is inferior to other fully FOSS products, then I will move to Fedora or other, less fragmented and more feature ecosystems - as is my duty as a user.

Personally, just like Unity, I'd rather Canonical ditch snaps all together if this is the quality of software we can expect from them. Don't do what you're bad at - you suck at user experience.

The only really sensible use case for Snaps, if any, is packaging software that will never make it into an official repository, like some 3rd party software, e.g. MS-Office suite, or Photoshop. Servers use docker or podman to deploy services. But what ever you do, please sort out the mess with snap. Allow if not user control as to where things go, then at a system wide level, or failing that just at least pick sensible defaults for your hardwired locations:

~/snap -> ~/.local/snap
/snap -> /usr/snap
etc

Hide snap specific loopback mounts in df.

Snap is currently a mess and just sorting this one ticket would probably stop quite a bit of the pushback you are getting on Snap. Obviously there are many other things wrong with snap as stated elsewhere, but actioning this one, not terribly difficult ticket
would bring big dividends to user perception.

It's been 8 years for this ticket! I think this speaks volumes in terms of the level of support that end users are going to get on snap going forward.