Ubuntu

Hyper-V VSS FREEZE fails with 'access denied' on /run/user/$UID/doc

Asked by Jon

I've got 4 similar Ubuntu 20.04 LTS VMs running on Server 2016 Hyper-V. One of these fails to create a successful production checkpoint in Hyper-V after the user logs into the VM GUI (using xRDP). Searching /var/log/syslog on the VM shows this:

Sep 29 03:03:46 devbuntu Hyper-V VSS: VSS: op=CHECK HOT BACKUP
Sep 29 03:03:47 devbuntu Hyper-V VSS: FREEZE of /run/user/1042339/doc failed; error:13 Permission denied
Sep 29 03:03:47 devbuntu Hyper-V VSS: VSS: op=FREEZE: failed
Sep 29 03:03:47 devbuntu Hyper-V VSS: op=5 failed!
Sep 29 03:03:47 devbuntu Hyper-V VSS: report it with these files:
Sep 29 03:03:47 devbuntu Hyper-V VSS: /etc/fstab and /proc/mounts

I read this as a failure caused by the Hyper-V VSS integrations in Ubuntu get 'access denied' when trying to "FREEZE" "/run/user/1042339/doc" because it doesn't have access to the fuse mount.

A view of 'mount |grep /run/user/1042339/doc" and google searches indicate "/run/user/1042339/doc" is a FUSE mount point for xdg-desktop-portal with supports flaptack/snap. However there doesn't appear to be any snaps or flatpack installed on this machine.

Out of the four machines, this is the only one with the /run/user/1042339/doc mount--and the only system that fails to create a production checkpoint via Hyper-V. A similar fuse mount on /run/user/$UID/gvfs is present on all four machines, but does NOT cause these issues.

So my questions are:
How can I prevent/modify the fuse mount (or whatever is creating it) to allow Hyper-V VSS FREEZE function to succeed?

Does this conflict need to be reported as a bug in Hyper-V VSS, fuse, or xdg-desktop-portal?

Further info:
lsof /run/user/1042339/doc
lsof: status error on /run/user/1042339/doc: Permission denied
lsof 4.93.2

mount |grep /run/user/1042339/doc
/dev/fuse on /run/user/1042339/doc type fuse (rw,nosuid,nodev,relatime,user_id=1042339,group_id=2121042339)

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>
/dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=3295-E5AE /boot/efi vfat umask=0077 0 1
/dev/mapper/vgubuntu-swap_1 none swap sw 0 0

uname -a
Linux is-ubuntu 5.11.0-36-generic #40~20.04.1-Ubuntu SMP Sat Sep 18 02:14:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Question information

Language:
English Edit question
Status:
Expired
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#1

Why is the user using xRDP? What is the user doing that needs the full desktop session? There may be a sleeker solution to what you want to achieve and bypass the issue

Revision history for this message
Jon (jtlarson07) said : 		#2

The users need to use applications that require the GUI, so I think that whether we use xRDP, VNC, or another option, the dependency on the GUI--and therefore xdg-desktop-portal--is unavoidable.

Am I wrong?

Revision history for this message
Manfred Hampl (m-hampl) said : 		#3

"Further info:
lsof /run/user/1042339/doc
lsof: status error on /run/user/1042339/doc: Permission denied"

lsof usually needs admin rights, e.g. with sudo

Revision history for this message
Jon (jtlarson07) said : 		#4

The "lsof /run/user/1042339/doc" was run as root, i.e.

# lsof /run/user/1042339/doc
lsof: status error on /run/user/1042339/doc: Permission denied

My understanding is that permission denied message is expected because root cannot access a fuse mount of another user unless it was created with "allow_root" option--which is not the case here as you can see from the mount info I provided:

mount |grep /run/user/1042339/doc
/dev/fuse on /run/user/1042339/doc type fuse (rw,nosuid,nodev,relatime,user_id=1042339,group_id=2121042339)

Revision history for this message
Manfred Hampl (m-hampl) said : 		#5

What about

sudo --user=1042339 lsof /run/user/1042339/doc
(or sudo --user=\#1042339 lsof /run/user/1042339/doc)

What is the difference between the system where it fails and the other ones where it works?
(maybe apparmor, selinux, ...)

Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#6

Depends on the application used. What applications are they using?

Revision history for this message
Jon (jtlarson07) said (last edit ): 		#7

Manfred Hampl>What is the difference between the system where it fails and the other ones where it works?

Simply put, it's the presence of the /run/user/1042339/doc mount--it doesn't get created on the other systems. The issues showed up weeks after the system was first created--i.e. it's related to something the user installed when trying to optimize their workflow, but neither the user nor I know which process/application is doing it or why. When I tracked the errors in the snapshot process back to the mount, I couldn't find any process that was using the mount (using lsof), and after investigating I was able to umount it without issue. So in summary--something in this user's desktop environment is creating the mount but doesn't appear to be using it consistently, so I haven't been able to figure out which process is causing it. That's why I asked the questions I did, and perhaps I should add one more:

How could I log what process initiated/used a fuse mount point?

How can I prevent/modify the fuse mount (or whatever is creating it) to allow Hyper-V VSS FREEZE function to succeed?

Does this conflict need to be reported as a bug in Hyper-V VSS, fuse, or xdg-desktop-portal?

actionparsnip>Depends on the application used. What applications are they using?

With all due respect, I think this is a fruitless line of inquiry for two reasons:

1. They use docker, VS Code, browsers, git, etc... I don't know the whole list, but the point is that this team has specifically asked for a Ubuntu desktop system. Your apparent suggestion that we should abandon the xRDP GUI-based workflow because of this bug/config issue seems to be out of proportion--like suggesting that someone abandon their house because the stairs creek.

2. Three other systems have this same Ubuntu desktop and it's dependencies--including xdg-desktop-portal. That tells me that the issue isn't with the GUI or default set of programs, but rather a config error or bug arising from this user's configuration. I'm just asking for help in locating the specific conditions that are creating this issue.

Revision history for this message
Launchpad Janitor (janitor) said : 		#8

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Jon (jtlarson07) said : 		#9

Update: This mount point seems to be created (but not used?) when users run Chrome on the Ubuntu desktop.

Package: google-chrome-stable
Version: 95.0.4638.69-1

Revision history for this message
Launchpad Janitor (janitor) said : 		#10

This question was expired because it remained in the 'Open' state without activity for the last 15 days.