There it is. Thank you. Your Plex user doesn’t own the library. it came in from somewhere else and the permissions were manually obliterated by something/someone.
drwxr-xr-x 5 plex plex 4096 May 15 2016 .
drwxr-xr-x 85 plex plex 4096 Feb 28 22:47 ..
drwxrwxrwx 3 1024 users 4096 Jan 31 2014 Library
Please repair by doing the following.
Stop Plex
sudo chown -R plex:plex /var/lib/plexmediaserver
sudo find /var/lib/plexmediaserver -type d -exec chmod 755 {} \;
sudo find /var/lib/plexmediaserver -type f -exec chmod 644 {} \;
Now run the normal installation.
Restart PMS
This is part of what I need to resolve. I am going to speak with the team and see how much time I have before next PMS release. I’m going to try and incorporate this condition so I can report what needs to be done.
In short, the PMS installation is badly compromised and in need of repair at the ownership & permission level (which I’ve shown how to perform in my steps above)
Has the problem with installing PMS on a systemd-nspawn container been resolved yet? I’ve been lurking on this thread since the new year, when updating via apt broke my PMS install. After reading the comments, the only way I’m able to upgrade is to manually download the updated .deb package, and install it this way:
EDIT: I just read that the package install at least does not abort anymore with v1.19, that is great, many thanks for fixing this! I’ll recheck the new package, once up, to see whether the below points are still a topic, but from what I see they are, since messing with admins custom configs/choices is still something I would never do within a deb package config script.
I understand that for you guys it is easier to debug and handle things without any custom drop-in configs, but that makes the package very unflexible and when users running such dpkg configure issue, it can be very hard to solve it at all for inexperienced users and dpkg denies to do any further installs/upgrades until the issue is solved.
systemd supports any name.service.d/*.conf file like this is the case and intention for all these kind of name.d/-style drop-in configs. There is no functional reason for not allowing admins and 3rd-party software/installers do add individual configs, in separate files sorted, according to their needs. Also for debugging reasons it doesn’t complicate things since putting everything into override.conf or separate files has no practical difference + files could be added after the package has been installed, hence the whole content must be anyway checked to be sure no customisation is the culprit.
According to official systemd support: systemd.unit
In addition to /etc/systemd/system , the drop-in " .d/ " directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib . Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.
Not a word about any deprecation. override.conf is just the default created when using systemctl edit name.service. Otherwise do you have some source about any such deprecation? Because then I would need to address this to systemd devs, being a very bad limitation .
I found the plexmediaserver.preinst and I must say it does ALOT of checks, which limits admins flexibility and as well goes far beyond anything that one will see on official Debian packages (as you mentioned distro/systemd standards above). And even systemd unit modifications from existing override.conf are patched into the new systemd service, which is a bid confusing to me,as custom changes cannot be easily reverted then, for fix and debugging reasons. Wouldn’t it be easier to handle all of this via native deb package conffiles implementation?
So:
On fresh install everything is setup/configured as intended standard.
If there have not been done any custom modifications to the systemd unit, package upgrades will upgrade the old file silently.
If there have been done custom modifications to the systemd unit, depending on local APT config, admin is asked by dpkg whether to keep or replace the existing systemd unit, or choice is done according to APT/dpkg config.
The new systemd unit is installed besides the old one with -dpkg-new or -dpkg-dist file name suffix, for comparison and manual replacement.
Any drop-ins would be left in place, non-parsed, non-handled, as this is totally up to the admin to take care of these customisation.
This is how packages usually behave and I guess most admins are expecting it. If the service fails, local customisation are then easy to check/fix/revert as they are well sorted in separate files.
I am a bit dismayed to receive such input this late in the process.
Sorry for that, I was not aware of that Linux installer beta phase. I am not using PMS myself regularly but taking care about the installer for DietPi. Since we use name.service.d configs in many cases, e.g. to apply custom CPU/IO priorities/nice or when we want services to run as shared group so that multiple software titles (downloaders, media players, network shares, cloud servers, …) have write access to the same files without making them world-writable. In such cases I prefer to not edit any existing file, but always create drop-in configs so that changes are transparent, can be reverted easily or again overridden by another drop-in config with higher alphabetical order.
I read through the design criteria and while I do not agree this all being necessary or even helpful for frontend software packages, I think you made your choice/discussion about this with reason. Instead of re-discussing the fundamental approach, I think it’s more constructive when I wait for v1.19, see how thinks work out for us and concentrate on targeted feedback/requests if/where they don’t .
Ah and I hope my input does not sound harsh/unfriendly or such, I guess my writing style might imply such impressions by times . Finally package design is also a question of personal taste and while there are always the ones that are unhappy with decisions, there are the others, that cannot away them.
Skilled Linux users will find it annoying in some regards
Other skilled linux users have made it clear they like all the information and checks for “fat fingering”
Many different skill levels come to Linux and apply “Joe Unknown’s Plex installation procedure”.
Guess who gets to cleanup that mess?
I do get the impression you don’t work in the support side. I’ve been a hard core developer for 30 years and now have backed down a bit. This is a completely different animal.
If you’re interested, I would like to take this to private messaging and discuss a few things which don’t belong in a public “Problems” thread.
1.19.0 is looking good to me but I don’t have DVR capability so I can’t speak to how good is is for DVR.
I can speak directly to the package installation.
1.19.0 has more than 10 corrections & improvements in it. IIRC, It has 16 although only 10 are probably going to be listed.
In this packaging update, the high points are:
I changed how parameters are passed between stages (pre - post) to be more secure just in case something happens to your system.
SYSV-init had a startup bug since launch at 1.18.5. I’ve resolved it. I’ve also removed start_pms because it’s no longer needed in the new SYSV-init service-oriented mechanism.
Improved its ability to handle older non-POSIX compliant implementations (spaces in user/group names)
Added support for IPA environments (LDAP servers, etc)
Relaxed the strictness with containers. Recognized containers (Docker, etc) are handled per their request (linuxserver.io, binhex, etc). Custom (user defined) containers are given full “hands off”. Such contains effectively get a 'drop the files and walk away" handling.
systemd handling was standardized to release version 242 with eyes on 245. I wanted to be able to process the environment exactly how systemd has it but, due to a design choice (or perhaps bug) in systemd itself, I can’t. It refuses to print Environment variables which have spaces in them e.g. "/var/lib/plexmediaserver/Library/Application Support". It doesn’t like quotes either yet it accepts quoted variables for input. Strange. That notwithstanding
a. Don’t abort if multiple overrides found
b. Use override.conf as the preferred override if multiple are found because systemctl edit writes this file. This handles 99+% of the use cases
c. Local.conf is a common override file name. It’s second in priority.
d. These two not having been found, I will accept the first of *.conf found.
e, If more than one file exists, I warn that PMS may not work as expected and continue onward.
Unless there are glaring errors found, this will be the foundation for my next phases:
Step 1 - Port to RPM packaging
Step 2 - Integrate “now stable” DEB packaging into the mainstream debconf so you get the flexibility of debconf with the added information & checking of an actual valid runtime environment.
Step 3 - Perform similar integration with Redhat pkgconfig
While this is happening, I’ll continue my efforts to test on all the environments and see just how much solid compatibility is there. I already know it runs great on Gentoo w/ init and even Oracle Linux.
The challenge will be how to cope with, if possible, those older systems which only patched the glibc to be 2.14.1 . If they only patched that but still rely on their older packaging, then there will be limits and I won’t be able to run on those hosts.
From a practical sense; why should I support Ubuntu 10 / 12 or Fedora 16 if I can’t spin up a VM to test with?
For Debian/Ubuntu:
You could add some dependencies to the package, the required libc6 version you mentioned already and others if known, to simply block installs on too old distros? Otherwise check /etc/os-release and warn user if the distro version is below of what has been tested/proven sufficient. The download page as well shows Debian 8+/Ubuntu 16.04+, so I would not invest too much effort to test with outdated distro versions. If one really uses Debian Wheezy for some reason, one has to live with hopelessly outdated software anyway, or needs to compile everything oneself, where sources are available.
For RPM-based distros there will be a dependency system available as well to block install on outdated versions.
My instructions to this point are to only place the dependency on glibc 2.14.1
I have run into a few bumps with the extremely old package managers on those systems where folks updated glibc only. I’ve addressed what I can but DPKG itself is doing a good job at stopping the installation. I do trap those errors.
I have more work I’m doing to update the debian foundation which will carry more of the installation load. The current foundation is several years old ( version 8 ). I’m going to pull that as far forward as reasonably can.
One thing not stated on the download page yet is SYSV init support. I doubt it will be but such support does open the door for older versions.
I really do need to create a chart / table of some kind stating what the new Linux packaging support matrix is.
In a nutshell:
glibc_2.14.1 - Required for all
SYSV init -or- systemd
There are certain older init-based systems which will not be supported again by this packaging when it moves to RPM.
I wanted to open the door in the forward direction and not the antiquated stuff.
Fingers crossed.
Any idea about when 1.19 will make its appearance? I’m holding off on 1.18.8.2527 so I don’t have to manually download and fix the problems with the deb package.
from /var/lib/dpkg/info/plexmediaserver.preinst for 1.18.9.2571
# Having tested for Systemd, Init, and Docker containers, declare all others as custom and report
if [ $(($Systemd + $Init)) -eq 0 ]; then
# Inform user we detect a custom environment.
Output both "Custom environment detected. Skipping preinstallation validation."
# Put date/time stamp in log file for use in debugging
echo '# Plex Media Server installation configuration info: ' $(date) >>$InstConfig
# Flag as Custom and we're done.
echo Custom=1 >> $InstConfig
# Exit now
exit 0
fi
I was still required to sed -i 's/LinuxContainer=0/LinuxContainer=1/' /tmp/plexinstaller.log && dpkg --configure plexmediaserver in order to complete the installation.
The host is Arch. The container is Ubuntu. The kernel is Arch’s, and passed through. So, for packaging issues, the version of systemd is 237, as that is what the container sees. (The output of the host’s systemctl --version was shown to indicate which version of systemd-nspawn was booting the container.)
So, essentially, the current version of the PMS .deb does not properly recognize it is in a container if that container is of the systemd-nspawn type when the container’s OS is Ubuntu 18.04.4 LTS.
Are there any others using .deb packages with systemd-nspawn? If so, does PMS install/update correctly? Or am I the only person experiencing issues?
.
.
. Finally package design is also a question of personal taste and while there are always the ones that are unhappy with decisions, there are the others, that cannot away them.
.