Score:0

Ubuntu

chown operation isn't persistent after reboot on 20.04

Tartan_Spartan

3/8/23, 1:10 AM

Recently I have an issue where I have to use a tty to change permissions of my home directory back to my primary user and this happens at every boot. I have no idea what is causing this to not be persistent. How do I get to the bottom of this and avoid this annoying workaround in future?

Order of operations in tty:

login with UN & PW

sudo su

(now acting as root user)

cd home/seumas/

chown seumas .

(exit tty and log in graphically)

/etc/fstab contents

# /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>
# / was on /dev/sda2 during installation
UUID=435410b9-b4b3-4bcb-b300-8967be32612d /               ext4    noatime,errors=remount-ro 0       1

# /boot/efi was on /dev/nvme0n1p2 during installation
UUID=441E-E722  /boot/efi       vfat    umask=0077      0       1

# /home was on /dev/sda4 during installation
UUID=1b60b312-8481-4338-bab3-ba8a572ff3e0 /home           ext4    noatime,defaults        0       2

# swap was on /dev/sda3 during installation
UUID=f3e2d240-3a9c-4e0d-8a08-77704641c8a3 none            swap    sw              0       0

Output of ls -alFd:

drwx--x--- 106 seumas root 12288 Nov 23 15:13 ./

Output of /etc/passwd:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin
syslog:x:102:106::/home/syslog:/usr/sbin/nologin
messagebus:x:103:107::/nonexistent:/usr/sbin/nologin
_apt:x:104:65534::/nonexistent:/usr/sbin/nologin
uuidd:x:105:111::/run/uuidd:/usr/sbin/nologin
avahi-autoipd:x:106:112:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin
usbmux:x:107:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
dnsmasq:x:108:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
rtkit:x:109:114:RealtimeKit,,,:/proc:/usr/sbin/nologin
cups-pk-helper:x:110:116:user for cups-pk-helper service,,,:/home/cups-pk-helper:/usr/sbin/nologin
speech-dispatcher:x:111:29:Speech Dispatcher,,,:/var/run/speech-dispatcher:/bin/false
whoopsie:x:112:117::/nonexistent:/bin/false
kernoops:x:113:65534:Kernel Oops Tracking Daemon,,,:/:/usr/sbin/nologin
saned:x:114:119::/var/lib/saned:/usr/sbin/nologin
pulse:x:115:120:PulseAudio daemon,,,:/var/run/pulse:/usr/sbin/nologin
avahi:x:116:122:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/usr/sbin/nologin
colord:x:117:123:colord colour management daemon,,,:/var/lib/colord:/usr/sbin/nologin
hplip:x:118:7:HPLIP system user,,,:/var/run/hplip:/bin/false
geoclue:x:119:124::/var/lib/geoclue:/usr/sbin/nologin
gnome-initial-setup:x:120:65534::/run/gnome-initial-setup/:/bin/false
seumas:x:1000:1000:seumas,,,:/home/seumas:/bin/bash
postfix:x:122:127::/var/spool/postfix:/usr/sbin/nologin
nm-openvpn:x:124:132:NetworkManager OpenVPN,,,:/var/lib/openvpn/chroot:/usr/sbin/nologin
lightdm:x:125:133:Light Display Manager:/var/lib/lightdm:/bin/false
systemd-timesync:x:126:135:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
tss:x:127:136:TPM software stack,,,:/var/lib/tpm:/bin/false
tcpdump:x:128:138::/nonexistent:/usr/sbin/nologin
_flatpak:x:129:139:Flatpak system-wide installation helper,,,:/nonexistent:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
debian-tor:x:130:140::/var/lib/tor:/bin/false
postgres:x:131:141:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
test:x:1001:1001:,,,:/home/test:/bin/bash
gdm:x:121:125:Gnome Display Manager:/var/lib/gdm3:/bin/false

192

0 + 0

reboot

chown

persistence

20.04

PonJar

3/8/23, 8:37 AM

Each user will have their own home directory. When you open a terminal or file manager you will probably start at the home belonging to the user you have logged in as. This may be causing some confusion. I suggest you start at /home in the filesystem (not at ~) and cd down to the home of the user you are trying to change. If your user is tartan that will be at /home/tartan. If your other user is spartan that users home directory will be at /home/spartan

0

Reply

Tartan_Spartan

3/21/23, 8:32 AM

First of all I log into the TTY as myself before logging in graphically. I then use sudo su and have to do the chown operation. Only then when I log in graphically will the home directory be accessible to me. This has to be done on every boot. This is abnormal behaviour and I expect to be able to simply log on graphically without having to do this on every restart. What process is reverting the ownership on restart? Which logs do I have to study to diagnose this?

0

Reply

PonJar

3/21/23, 9:46 AM

What sort of storage device and what filesystem is this happening on? Can you save files in home and get persistence between boots? Can you add your /etc/fstab file as code in the question along with answers to my questions

0

Reply

Tartan_Spartan

3/23/23, 8:03 PM

This is on a 2.5" SSD installed inside an x86 laptop, using an ext4 filesystem. Yes, saved files persist between boots. Please see the main body of the question for the /etc/fstab file. Thank you for your help!

0

Reply

Thomas Ward

3/23/23, 8:15 PM

Instead of using nano and then copying from that, just run `cat /etc/fstab` and copy the output into your question as an edit. Nano adds a lot of extra symbols that make it a lot harder to work with the output. And no need to alter the delimiters, we'll fix the formatting problems when we apply code formatting.

0

Reply

Tartan_Spartan

3/23/23, 9:06 PM

Rewritten using cat output.

0

Reply

pasman pasmański

3/23/23, 9:25 PM

@Tartan Your question is unclear. Instead of *use sudo su and have to do the chown operation* , please paste exactly what you wrote in console. You may add it in your question.

0

Reply

NovHak

3/23/23, 9:58 PM

Did you install third party software ? Seeing the content of `/etc/passwd` could be interesting, as well as the output of `ll -d <directory>`, _<directory>_ being the affected directory, e.g. `ll -d /home/spartan`.

0

Reply

Tartan_Spartan

3/23/23, 11:21 PM

@pasmanpasmański Done. NovHak Most likely yes this was the cause. Output will now be edited into the question.

0

Reply

NovHak

3/24/23, 3:27 AM

@Tartan_Spartan You should have a look at `journalctl --system -b 0`, to see if that mysterious process is polite enough as to log what it's doing (it will show the system log for the current boot). You could try `journalctl --system -b -1` as well to check for the previous boot's system log, in case the ownership change is performed upon system shutdown or session logout. Those logs will be too big to fit in the question though...

0

Reply

PonJar

3/24/23, 8:30 AM

When you log in and don’t have ownership of your files can you check how far down the directory tree that goes. You said it took a long time to chown recursively. When you shutdown does it take a similar time? I’m wondering if the change of ownership is just at the top of the directory tree. Have you any friends who could be pranking you with a small script at shutdown. Journalctl should help find anything like that.

0

Reply

Tartan_Spartan

3/24/23, 9:00 AM

@NovHak here is -1: https://pastebin.com/HM1PEuFB & https://pastebin.com/zydnkNYy and 0: https://pastebin.com/xwr7NCdV & https://pastebin.com/DJMa7hr2 PonJar, I can check that tomorrow if you wish (I think it's pervasive throughout the entire directory). The shutdown was not a similar time to the chown recursively, it was much much shorter, on par with what would expect for a reboot time on an SSD. I don't let any friends access my laptop either in person or remotely. But I do want to get to the bottom of this and thank you for your help.

0

Reply

PonJar

3/24/23, 10:19 PM

May or may not be relevant: I don’t think “errors=remount-ro” is meaningful for ext4 in fstab. Could also try dropping the 2 at the end of the fstab line for /home. That could be running fstab every time you log in. It shouldn’t make a difference but process of elimination. I don’t think the paste bin links show the entire picture. Can you post the last 1000 lines of the b -1 version. Might be worth running the journalctl command with an additional -p 3 option. That will show you any errors being thrown which could lead to something.

0

Reply

NovHak

3/24/23, 11:46 PM

@Tartan_Spartan I didn't find anything mentioning an owner change. Moreover, your log paste is incomplete, some lines are truncated. It could be interesting that you repost them using the following method : 1. Execute `journalctl --system -b 0`, 2. While it's displayed, type s (lower case), and enter a file name that will contain the log and will be saved in the current directory, 3. Open that file in a text editor, e.g. gedit, 4. Select everything (Ctrl+A) and copy (Ctrl+C), and 5. Paste in Pastebin. The result will contain ANSI control characters too, but that's not a problem.

0

Reply

NovHak

3/24/23, 11:59 PM

And do the same for `journalctl --system -b -1`. The result will be viewable with `less -R` and even retain colored output, which improves readability. Tbh I doubt this will give the info that we're missing, but at least the logs will be complete. From what I saw though, I'm beginning to suspect Anbox, that's running in devmode. Maybe it could be interesting to disable it temporarily and see if it changes anything.

0

Reply

Tartan_Spartan

4/4/23, 8:15 PM

Apologies for the radio silence. 0: https://pastebin.com/9MBubDMP & https://pastebin.com/GWkamT1W & https://pastebin.com/U138U1gK & https://pastebin.com/h2CQz2Xc & https://pastebin.com/rcFJPCVj & https://pastebin.com/19dyhT8J . -1 will be forthcoming within a few hours. I did what you said except added the step of dividing the files using the split command to match filesize limits on Pastebin. I hope that didn't omit or truncate anything. Also, Anbox has not worked since this chown fiasco first occurred. Would like it back. I tried to install the devmode version of it as a fix, but no joy.

0

Reply

Tartan_Spartan

4/4/23, 10:48 PM

-1: https://pastebin.com/pRQkXpNp & https://pastebin.com/zeyQDCTz & https://pastebin.com/RH3Jvyjq & https://pastebin.com/3Pk3Accs & https://pastebin.com/TLaVamyp & https://pastebin.com/Sy7SwVSb & https://pastebin.com/zHqPumkH

0

Reply

Tartan_Spartan

4/4/23, 10:51 PM

Look, Pastebin doesn't seem to be cooperating at all for persisting these pastes. So I'm just going to chuck both files on a file transfer site and be done with it. At least this link will be active for a week. https://we.tl/t-SWiW83Ox5o

0

Reply

Tartan_Spartan

4/8/23, 8:48 AM

@NovHak please let me know when we can look at this again.

0

Reply

NovHak

4/8/23, 8:47 PM

Sorry, I wasn't notified until your last comment, I'm now following this question explicitly. Sending via Wetransfer worked well, however I still didn't find any reference to an ownership change. I noticed you seem to have a backup system (`/media/seumas/Backups`), is it by hand or automated somehow ?

0

Reply

NovHak

4/8/23, 9:00 PM

In the meantime before this gets resolved, you could try this as a workaround : `setfacl -m u:seumas:rwx /home/seumas`. It will set an extended ACL entry on your home directory, that will hopefully not be resetted, and ensure you still get read, write and execute access to your home directory after an owner change.

0

Reply

NovHak

4/8/23, 9:21 PM

Oh and btw, some time ago I asked you to run `ll -d /home/seumas` and you did something significantly different, by cd'ing to the directory first I suppose, then running the command on the current directory. This partially defeats the idea I had in mind, that is to detect if there's a symbolic link in the path. Let's go even further : could you try `ll -d /home /home/seumas` and give the result ?

0

Reply

Tartan_Spartan

4/8/23, 10:58 PM

Thank you. Tackling your points one by one, what do you mean by "by hand or automated somehow"? It is an NVMe SSD, created using the Backups program, which runs once per week using a password security system. Also, I just set the ACL entry, thank you for the tip there.

0

Reply

Tartan_Spartan

4/8/23, 11:04 PM

Output for the final command you provided: `drwxr-xr-x 5 root root 4.0K Nov 6 03:49 /home drwxrwx---+ 106 seumas root 12K Dec 7 19:16 /home/seumas`

0

Reply

NovHak

4/9/23, 2:40 PM

OK, so your backup system is automated. But since you use the Ubuntu-provided program, and it only runs once per week, that's likely not the problem. There is no symlink between the root directory and your home directory either, so that's another thing to put aside. I can see that you've added set the ACL entry (the `+` after `drwxrwx---`). Now it would be interesting to confirm that the ext. ACL entry persists across reboots. Otherwise, maybe it would mean the directory inode is defective. Can you give the output of `lsattr -d /home/seumas` ?

0

Reply

NovHak

4/9/23, 3:07 PM

That being said, rather than the filesystem, the problem most likely comes from a program that's explicitly chowning your home directory. Can you give the result of `systemctl --system list-dependencies`. Again, it may be better that you save and share this the same way as you did with the journal (type lowercase `s` etc...). Maybe we can have a look at `systemd-analyze plot >servinit.svg`. `servinit.svg` is the name of the file where the result is saved, you can choose any name you prefer, then share this file. It's an SVG format document that can be viewed with an image viewer.

0

Reply

NovHak

4/9/23, 3:10 PM

Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/132193/discussion-between-novhak-and-tartan-spartan).

0

Reply