Files disappearing from home folder

Hello, I’ve had EndeavourOS installed for about 2 weeks now and I’m loving it. However, I have a really weird issue where files in my home folder are disappearing on reboot. For example, I have wallpapers in my ~/Wallpapers folder, and some patchbay files for qpwgraph in my ~/Patches folder. On reboot, they’re gone, and I’ll have no more wallpaper or I have to re-create my patches. I’m not sure where to even look to see where the problem be coming from.

Out of all the things I’ve installed, I have a feeling it might be zsh related? I have oh-my-zsh installed, along with the powerlevel10k theme. I’m also using i3 for the window manager. Anyone know what the problem could be or where I can start looking?

Could you share the output of lsblk and cat /etc/fstab?

Here you go:

❯ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931.5G  0 disk 
├─sda1        8:1    0    16M  0 part 
├─sda2        8:2    0   540G  0 part 
└─sda3        8:3    0 391.5G  0 part /
sdb           8:16   0 447.1G  0 disk 
├─sdb1        8:17   0    16M  0 part 
└─sdb2        8:18   0 447.1G  0 part 
zram0       254:0    0     4G  0 disk [SWAP]
nvme0n1     259:0    0 238.5G  0 disk 
├─nvme0n1p1 259:1    0   499M  0 part 
├─nvme0n1p2 259:2    0    99M  0 part 
├─nvme0n1p3 259:3    0    16M  0 part 
└─nvme0n1p4 259:4    0 237.9G  0 part 
❯ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=6756f34b-cd0f-45af-b85f-4f7a94264f43 /              ext4    noatime    0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

My first guess was that you are mounting some partition in your home partition, but that doesn’t seem to be the case. What are you doing with all the other partition on sda, sdb and nvme0n1?

Maybe the tmpfs is somehow doing something to those folders? But I’m not sure how any why.

I doubt zsh is doing anything. Maybe you could search for “Wallpaper” and “Patches” in every file in your home directory. Maybe there is something in there that modifies/uses that directory.

grep -Rnw ~/ -e 'Wallpaper'
grep -Rnw ~/ -e 'Patches'

Really weird. Which file manager are you using? Can you do an ls in one the directories before reboot, to see the files are actually there.

maybe try https://www.baeldung.com/linux/sync-command

Well how is it possible that you have multiple disks mounted but not through fstab?

I mean there is only one disk in fstab but blkid finds 2 hard drives and 1 nvme disk?

those aren’t mounted, probably they are for some other os

@mihalycsaba mentioned other OS installations. Could it be that another OS is accessing those partitions somehow?

Can you share the output of findmnt and ls -ld ~/Wallpapers

Sorry, I forgot to mention that I’m dual booting from Windows. It was all originally Windows partitions, but wanted to switch to Linux without fully committing, so I took one disk, shrunk it, and used that as the Linux partition.

I can confirm the files exist before reboot.

❯ findmnt
TARGET                   SOURCE      FSTYPE          OPTIONS
/                        /dev/sda3   ext4            rw,noatime
├─/dev                   devtmpfs    devtmpfs        rw,nosuid,size=4096k,nr_inodes=2024654,mode=755,inode64
│ ├─/dev/hugepages       hugetlbfs   hugetlbfs       rw,nosuid,nodev,relatime,pagesize=2M
│ ├─/dev/mqueue          mqueue      mqueue          rw,nosuid,nodev,noexec,relatime
│ ├─/dev/shm             tmpfs       tmpfs           rw,nosuid,nodev,inode64
│ └─/dev/pts             devpts      devpts          rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
├─/sys                   sysfs       sysfs           rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/debug    debugfs     debugfs         rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/tracing  tracefs     tracefs         rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/fuse/connections
│ │                      fusectl     fusectl         rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security securityfs  securityfs      rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup       cgroup2     cgroup2         rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursive
│ ├─/sys/fs/pstore       pstore      pstore          rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/bpf          bpf         bpf             rw,nosuid,nodev,noexec,relatime,mode=700
│ └─/sys/kernel/config   configfs    configfs        rw,nosuid,nodev,noexec,relatime
├─/proc                  proc        proc            rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc
│                        systemd-1   autofs          rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,di
│   └─/proc/sys/fs/binfmt_misc
│                        binfmt_misc binfmt_misc     rw,nosuid,nodev,noexec,relatime
├─/run                   tmpfs       tmpfs           rw,nosuid,nodev,size=3261500k,nr_inodes=819200,mode=755,ino
│ └─/run/user/1000       tmpfs       tmpfs           rw,nosuid,nodev,relatime,size=1630748k,nr_inodes=407687,mod
│   ├─/run/user/1000/doc portal      fuse.portal     rw,nosuid,nodev,relatime,user_id=1000,group_id=1001
│   └─/run/user/1000/gvfs
│                        gvfsd-fuse  fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1001
└─/tmp                   tmpfs       tmpfs           rw,noatime,inode64
❯ ls -ld ~/Wallpapers
drwxr-xr-x 2 slumpy slumpy 4096 Jan 31 11:10 /home/slumpy/Wallpapers

Try making one of the files immutable and see if it survives the reboot.

with all the info I’ve seen I am not surprised this is happening at all (too many chiefs).
but why?
symlinks v. hardlinks; thrown in permissions?

I’m not sure what you mean? I’m not doing anything outside the ordinary, AFAICT. Dual booting is very common, I’ve had no issues in the past with dual booting. This is my first time using Arch so I figured it was Arch related.

In any case, it looks like the problem no longer occurs for whatever reason. The only thing I’ve done was bump up zram and run a system update so maybe it was related to something there? Hopefully the issue’s gone for good but I’ll be back if it comes back.

Thanks everyone for their help!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.