Thanks a lot for your posting! Could you please paste the output of the following two commands here?
$ snap version
and
$ snap list
thanks you!
snap version
snap 2.27.4-1
snapd 2.27.4-1
series 16
debian unknown
kernel 4.12.0-1-amd64
and
snap list
Name Version Rev Developer Notes
castersoundboard 0+git.c41a4f2 34 rikai -
core 16-2.26.14 2462 canonical core,devmode
krita 3.2.0 26 krita -
warzone2100 3.2.3 5 diddledan -
1 Like
Can you please pastebin /snap/*/*/meta/snap.yaml - that is, all the snap.yaml files you have in /snap
Hmm, all of the data looks correct. I’ll look at possible bugs in the source that would explain this.
Would explain why other apps seem broken. The Warzone2100 one was compiled only last night though which makes it as fresh as it can be.
Hey ho.
I have a theory I’d like to confirm with you. Can you please run and paste:
ls -l /snap/core/
ls -l /snap/core/
total 0
drwxr-xr-x 24 root root 321 Jul 20 13:45 2462
So you don’t have anything (not even mount points) there and yet somehow snap list shows that you have a core snap. Can you please pastebin /proc/self/mountinfo as well as tell us if you are using some kind of container technology? Can you look at your journalctl output and also paste snap changes for further analysis.
cat /proc/self/mountinfo
18 24 0:18 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
19 24 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:14 - proc proc rw
20 24 0:6 / /dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=16332732k,nr_inodes=4083183,mode=755
21 20 0:19 / /dev/pts rw,nosuid,noexec,relatime shared:3 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
22 24 0:20 / /run rw,nosuid,noexec,relatime shared:5 - tmpfs tmpfs rw,size=3270744k,mode=755
24 0 254:11 / / rw,relatime shared:1 - ext4 /dev/mapper/kratoforn–vg-root rw,errors=remount-ro,data=ordered
25 18 0:7 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:8 - securityfs securityfs rw
26 20 0:22 / /dev/shm rw,nosuid,nodev shared:4 - tmpfs tmpfs rw
27 22 0:23 / /run/lock rw,nosuid,nodev,noexec,relatime shared:6 - tmpfs tmpfs rw,size=5120k
28 18 0:24 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:9 - tmpfs tmpfs ro,mode=755
29 28 0:25 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:10 - cgroup2 cgroup rw
30 28 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:11 - cgroup cgroup rw,xattr,name=systemd
31 18 0:27 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:12 - pstore pstore rw
32 18 0:28 / /sys/firmware/efi/efivars rw,nosuid,nodev,noexec,relatime shared:13 - efivarfs efivarfs rw
33 28 0:29 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,cpu,cpuacct
34 28 0:30 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,perf_event
35 28 0:31 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,net_cls,net_prio
36 28 0:32 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,blkio
37 28 0:33 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,freezer
38 28 0:34 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:20 - cgroup cgroup rw,pids
39 28 0:35 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,memory
40 28 0:36 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:22 - cgroup cgroup rw,devices
41 28 0:37 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:23 - cgroup cgroup rw,cpuset
42 19 0:38 / /proc/sys/fs/binfmt_misc rw,relatime shared:24 - autofs systemd-1 rw,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2324
43 20 0:17 / /dev/mqueue rw,relatime shared:25 - mqueue mqueue rw
45 18 0:8 / /sys/kernel/debug rw,relatime shared:26 - debugfs debugfs rw
44 20 0:39 / /dev/hugepages rw,relatime shared:27 - hugetlbfs hugetlbfs rw
46 22 0:40 / /run/rpc_pipefs rw,relatime shared:28 - rpc_pipefs sunrpc rw
78 24 7:2 / /snap/krita/25 ro,nodev,relatime shared:29 - squashfs /dev/loop2 ro
76 24 7:0 / /snap/core/2462 rw,relatime shared:30 - squashfs /dev/loop0 ro
77 24 7:1 / /snap/warzone2100/5 ro,nodev,relatime shared:31 - squashfs /dev/loop1 ro
82 24 7:3 / /snap/castersoundboard/34 ro,nodev,relatime shared:32 - squashfs /dev/loop3 ro
84 24 7:4 / /snap/krita/26 ro,nodev,relatime shared:33 - squashfs /dev/loop4 ro
86 24 7:5 / /snap/castersoundboard/21 rw,relatime shared:34 - squashfs /dev/loop5 ro
88 24 259:2 / /boot rw,relatime shared:35 - ext2 /dev/nvme0n1p2 rw,block_validity,barrier,user_xattr,acl
90 88 259:1 / /boot/efi rw,relatime shared:36 - vfat /dev/nvme0n1p1 rw,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
92 24 0:41 / /home rw,relatime shared:37 - btrfs /dev/mapper/kratoforn–vg-home rw,ssd,space_cache,subvolid=5,subvol=/
94 24 254:1 / /usr/src rw,relatime shared:38 - xfs /dev/mapper/vg_ssd-src rw,attr2,inode64,noquota
95 24 254:2 / /mnt/WinGame rw,relatime shared:39 - xfs /dev/mapper/vg_ssd-WinGame rw,attr2,inode64,noquota
98 94 254:0 / /usr/src/git rw,relatime shared:40 - xfs /dev/mapper/vg_ssd-git rw,attr2,inode64,noquota
100 42 0:44 / /proc/sys/fs/binfmt_misc rw,relatime shared:41 - binfmt_misc binfmt_misc rw
502 22 0:50 / /run/user/120 rw,nosuid,nodev,relatime shared:390 - tmpfs tmpfs rw,size=3270740k,mode=700,uid=120,gid=125
458 24 254:7 / /var/lib/libvirt/images/Kali-store rw,relatime shared:399 - xfs /dev/mapper/vg_ssd-Kali–store rw,attr2,inode64,noquota
536 22 0:51 / /run/user/1000 rw,nosuid,nodev,relatime shared:465 - tmpfs tmpfs rw,size=3270740k,mode=700,uid=1000,gid=1000
548 536 0:53 / /run/user/1000/gvfs rw,nosuid,nodev,relatime shared:475 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=1000,group_id=1000
559 18 0:52 / /sys/fs/fuse/connections rw,relatime shared:485 - fusectl fusectl rw
571 24 0:57 / /keybase rw,nosuid,nodev,relatime shared:494 - fuse /dev/fuse rw,user_id=1000,group_id=1000
308 22 0:20 /snapd/ns /run/snapd/ns rw,nosuid,noexec,relatime - tmpfs tmpfs rw,size=3270744k,mode=755
320 92 0:46 / /home/user/mnt/veritanuda@gd rw,nosuid,nodev,relatime shared:292 - fuse.google-drive-ocamlfuse google-drive-ocamlfuse rw,user_id=1000,group_id=1000
So you have the core snap mounted on /snap/core/2462 but /snap/core is empty. Something very curious must have happened there.
*shrugs* Beyond me. I am kinda new to snaps. 
[EDIT: removed incorrect observation]
Are you using any container systems? Is systemd your init system?
I am using systemd yes. No real containerisation per se. Encrypted hard drive though and btrfs /home for snapshoting
That’s all fine. I’m still wondering what has happened. I wonder if the system will be back to life if you reboot (though please check systemctl status before and after, some services may have failed with interesting information).
Already rebooted today 
I could purge the install and try again. Not sure if that will do anything and certainly won’t explain what is going on right now.
Please hold on for a few more hours if you can. Your system may have some important details about what has happened.
Did you check system logs / journal for any clues? Do you have any cron jobs / backup scripts that may have messed up /snap by accident?
Nope. I only installed snapd a week or so ago just to see if it worked. First app I have installed is castersoundboard. Then the Warzone2100 and finally Krita just to test. Here is the log for snapd from the journal:
Edit:
Actually this is the whole log.
journalctl -xu snapd
-- Logs begin at Wed 2017-09-06 09:53:17 BST, end at Wed 2017-09-06 13:12:37 BST. --
Sep 06 09:53:17 kratoforn systemd[1]: Starting Snappy daemon...
-- Subject: Unit snapd.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit snapd.service has begun starting up.
Sep 06 09:53:18 kratoforn snapd[1190]: 2017/09/06 09:53:18.180005 daemon.go:252: started snapd/2.27.4-1 (series 16; classic; devmode) debian/unknown (amd
Sep 06 09:53:18 kratoforn systemd[1]: Started Snappy daemon.
-- Subject: Unit snapd.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit snapd.service has finished starting up.
--
-- The start-up result is done.
Sep 06 11:38:18 kratoforn snapd[1190]: 2017/09/06 11:38:18.508076 snapmgr.go:429: No snaps to auto-refresh foundOk something weird is going on here. You know I did snap refresh and there was nothing to refresh. I just did snap refresh core and it pulled a newer core down. However, something odd seems to have happened in that a new /root/snap dir has been made which has castersoundboard and core in it.
ls -l /root/snap
total 8
drwxr-xr-x 4 root root 4096 Sep 6 13:22 castersoundboard
drwxr-xr-x 4 root root 4096 Sep 6 13:25 core
Is that supposed to happen?
Oddly enough though, now when I run castersoundboard as a nornmal user it works. So aside from a new core nothing else seems to have changed.
snap list
Name Version Rev Developer Notes
castersoundboard 0+git.c41a4f2 34 rikai -
core 16-2.27.5 2774 canonical core
krita 3.2.0 26 krita -
warzone2100 3.2.3 5 diddledan -
Curiouser and curiouser…
Yes, this is harmless. This is $SNAP_USER_DATA for the root user.
I think it works because you now have a valid core snap.
PS: Use triple backtick for things like shell output, it has nicer non-proportional font and thus output looks more like a terminal.