I purged and marked snapd hold to prevent reinstall. Get rid of it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1662552
Title:
snaps don't work with NFS home
To manage notifications about this bu
I've solved my snap challenges problems with the following state entry
in Saltstack
cleanup_snapd:
pkg.purged:
- name: snapd
pkg.held:
- name: snapd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
My solution has been to fully remove all snap functionality.
sudo apt purge snapd
sudo rm -vrf /snap /var/snap /var/lib/snapd /var/cache/snapd /usr/lib/snapd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
The KDE_HOME_READONLY workaround stopped working and failure behavior
changed last week after I applied updates to kubuntu 20.04.
Instead of a logout as previously experienced, NFS home now results in a
black screen with a mouse pointer.
See attached apt history.log and .xsession-errors for more
Created attachment 129548
apt history.log
apt history log showing updates that correspond to timing of
KDE_HOME_READONLY workaround no longer working.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/177
Created attachment 129549
.xsession-errors
.xsession-errors file for new black screen behavior after recent
updates. Note that the read-only home directory error is no longer
displayed, so not sure how this relates to previous behavior.
--
You received this bug notification because you are a mem
I can confirm this bug and workaround on kubuntu 20.04.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04 LTS
Release:20.04
Codename: focal
$
$ ls -la $HOME/.config/plasma-workspace/env/nfs_home_workaround.sh
-rwxr-xr-x 1 ---
** Package changed: snapd (Ubuntu) => kubuntu-meta (Ubuntu)
** Package changed: kubuntu-meta (Ubuntu) => kubuntu-packaging
** Project changed: kubuntu-packaging => kubuntu-meta (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Reproducible on 20.04.
kelleher@numbersix:~$
kelleher@numbersix:~$ lsb_release -rd
Description:Ubuntu 20.04 LTS
Release:20.04
kelleher@numbersix:~$
kelleher@numbersix:~$ apt-cache policy kubuntu-desktop
kubuntu-desktop:
Installed: 1.398
Candidate: 1.398
Version table:
*** 1.3
Public bug reported:
If a users home directory is an NFS server, KDE fails to start with the
error "No write access to $HOME directory". The fact that the error is
logged to .xsession-errors in the users home directory is a bit ironic.
This is reproducible on 20.04 and 18.04
kelleher@numbersix:~
** Also affects: kde-baseapps
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1774902
Title:
kubuntu - can't login with NFS $HOME
To manage notifications a
Anyone know if this affects KDE on 19.10?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1774902
Title:
kubuntu - can't login with NFS $HOME
To manage notifications about this bug go to:
https://bug
Sorry - those last two comments were meant for bug #1827286.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1577575
Title:
NFS share does not mount on boot using fstab
To manage notifications about
I did a little more testing and this looks to be specific to /home.
Even mounting over /home (no linking) with autofs results in the same
issue.
All autofs files as well as the list of packages installed have been
attached.
As a side note, having /home as a link is an artifact of some very old b
I did a little more testing and this looks to be specific to /home.
Even mounting over /home (no linking) with autofs results in the same
issue.
All autofs files as well as the list of packages installed have been
attached.
As a side note, having /home as a link is an artifact of some very old b
** Attachment added: "chi.packages"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261280/+files/chi.packages
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Tit
** Attachment added: "chi.packages"
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1577575/+attachment/5261278/+files/chi.packages
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1577575
T
** Attachment added: "auto.master"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261274/+files/auto.master
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title
** Attachment added: "auto.direct1"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261267/+files/auto.direct1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Tit
** Attachment added: "auto.net"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261269/+files/auto.net
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title:
au
** Attachment added: "auto.misc"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261271/+files/auto.misc
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title:
** Attachment added: "auto.smb"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261268/+files/auto.smb
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title:
au
** Attachment added: "autofs.conf"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261266/+files/autofs.conf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title
** Attachment added: "master.d_direct1.autofs"
https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/1827286/+attachment/5261265/+files/master.d_direct1.autofs
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
Looks like the issue is symlinking to a director prior to autofs
mounting it.
Everything fine...
root@numbersix:/# ssh chi uname -a
Linux chi 4.4.0-146-generic #172-Ubuntu SMP Wed Apr 3 09:00:08 UTC 2019 x86_64
x86_64 x86_64 GNU/Linux
root@chi:~# ls -la /home
ls: cannot access '/home': No such f
** Tags added: autofs
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827286
Title:
autofs - "Too many levels of symbolic links" after apt upgrade
To manage notifications about this bug go to:
http
Public bug reported:
Description:Ubuntu 16.04.6 LTS
Release:16.04
I moved to autofs this week as a workaround for Bug #1577575 failing to
mount NFS entries at boot. This worked file until I ran 'apt upgrade'
today.
Now trying to access /vol/home mount results in the following error:
Quick update - switched to autofs as a workaround for this 16.04 issue.
That was fine until I ran 'apt upgrade' today. Now I get the following
error:
root@chi:~# ls -la /vol/home/
ls: cannot access '/vol/home/': Too many levels of symbolic links
root@chi:~#
I'll be opening a new bug for autofs
I should note this is impacting an image built from 16.04.4. Another
image built from 16.04.1 is working fine.
Both have been pulled forward via apt dist-upgrade and their behaviors
differ - concerning in it's own right.
--
You received this bug notification because you are a member of Ubuntu
B
Same issue here. NFS fails to mount at boot, but logging in and issuing
a manual "mount -a" resolves until the next reboot.
It should also be noted that there's a significant delay on boot with
nfs entries in fstab - need to time it, but ~1 minute.
Why issues with something as old/stable/boring
The issue appears larger than just NFS mounted $HOME.
After I used the workaround provided to get the filebot snap to run with
an NFS mounted $HOME, I was unable to use it to manipulate any files in
my NFS mounted media library.
I gave up and just loaded the deb package.
Should this be reported
Public bug reported:
If $HOME is an NFS mount, startkde show a write error and fails to start
ksmserver.
Xsession: X session started for kelleher at Fri Jun 1 20:45:36 EDT 2018
localuser:kelleher being added to access control list
openConnection: connect: No such file or directory
cannot connec
32 matches
Mail list logo
