PMS created a 'Library' dir structure in my Synology /root

Server Version#: 1.41.1.9057-72009057
Player Version#: 4.141.0
Synology Model#: DS1019+
DSM Version#: 7.2.2-72806 Update 1

Note: PMS is installed as a native DSM application.

I was recently performing maintenance on my Synology DS1019+ when I noticed a rogue ‘Library’ subdirectory in my /root directory. Thankfully its only 354 KB in size, because the /root on a Synology is limited in space.

This directory appears to have been created recently:

# stat /root/Library
  File: /root/Library
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 900h/2304d      Inode: 59530       Links: 5
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-10-31 13:13:56.228094811 -0700
Modify: 2024-10-31 13:13:56.250095144 -0700
Change: 2024-10-31 13:13:56.250095144 -0700
 Birth: -

Some files have been changed as recently as 2024-11-04:

# stat "/root/Library/Application Support/Plex Media Server/plexmediaserver.pid"
  File: /root/Library/Application Support/Plex Media Server/plexmediaserver.pid
  Size: 5               Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d      Inode: 2141        Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-10-31 13:13:56.249095128 -0700
Modify: 2024-11-04 13:22:06.423506723 -0800
Change: 2024-11-04 13:22:06.423506723 -0800
 Birth: -

Reboots/changes do not seem to touch/modify the files beyond this point.

Contents of ‘/root/Library’:

# tree /root/Library
/root/Library
├── Application Support
│   └── Plex Media Server
│       ├── Codecs
│       │   └── 7592546-570471557d92948f58893deb-linux-x86_64
│       ├── Crash Reports
│       │   ├── 1.0.0.0
│       │   │   └── PLEX TUNER SERVICE
│       │   └── 1.41.1.9057-af5eaea7a
│       │       └── PLEX MEDIA SERVER
│       ├── Diagnostics
│       ├── Drivers
│       ├── plexmediaserver.pid
│       ├── Plug-in Support
│       │   └── Databases
│       │       ├── com.plexapp.plugins.library.db
│       │       ├── com.plexapp.plugins.library.db-shm
│       │       └── com.plexapp.plugins.library.db-wal
│       └── Preferences.xml
├── Caches
│   └── PlexMediaServer
│       ├── cl-icds-linux-x86_64
│       └── va-dri-linux-x86_64
└── Logs
    └── Plex Media Server
        ├── Plex Media Server.1.log
        ├── Plex Media Server.2.log
        ├── Plex Media Server.3.log
        ├── Plex Media Server.4.log
        ├── Plex Media Server.5.log
        ├── Plex Media Server.log
        ├── Plex Tuner Service.1.log
        └── Plex Tuner Service.log

20 directories, 13 files

Which package did you install on DSM ?

User ‘root’ is not used on Synology for user-privacy reasons (community requested).

If you’re using Container Manager (Docker) then your config is incomplete.

Hi Chuck, thank you for replying.

In this case, it was an update installed via the michealespinola/syno.plexupdate script which runs as ‘root’. Looking back at logs, and I apologize for not adding this to the original post, this was likely created by version 1.41.2.9134 (beta). The installation dates appear to coincide.

This is all native Synology DSM, and not Docker involved.

There is a scripting error here.

  1. the script runs as root (not a problem when you’re careful)
  2. the script calls dpkg (debian package manger) … Don’t use that in DSM 7.
  3. the correct utility to use on DSM 7 is synopkg
chuck@ds418:/usr/bin$ synopkg
usage: synopkg <command> [...]

command:
  start <package>                                                 Start a package.
  stop <package>                                                  Stop a package.
  restart [--service] <package|searvice>                          Restart one package/one or more services.
  resume <package>                                                Start a package without change its systemd enable status.
                                                                  It will do nothing if package is disable or already active.
  pause <package>                                                 Stop a package without change its systemd enable status.
                                                                  It will do nothing if package is already inactive.
  start-depend <service>                                          Start all packages depend on specific service.
  stop-depend <service>                                           Stop all packages depend on specific service.
  onoffall start|stop [event] [param]                             Start or stop all the packages.
  install <spk>                                 Install a package through local spk.
  install_from_server <package> [volume] [user] [beta]            Install a package from server.
  uninstall <package>...                                          Uninstall one or more package.
  upgradeall [limitonly] [lang] [user]                            Upgrade all upgradable package.
  chkupgradepkg [lang]                                            Find all upgradable packages from server, and decide whether to
                                                                  upgrade accorting to user settings.
  checkupdateall [lang] [user]                                    Find all upgradable packages from server (use cache first), and
                                                                  decide whether to upgrade accorting to user settings.
  status <package>                                                Get status of an installed package.
  is_onoff <package>                                              Check if a package is installed and active.
  version <package>                                               Get version of an installed package.
  query <spk>                                                     Get a package's basic information from the spk.
  list [--name] [--depend-on <package>]                           List installed package.
  checkupdate <package> [lang]                                    Check if a package is updatable.
  show [--beta] [--lang <lang>] <package>                         Show package details.
  showall [--beta] [--no-filter] [--lang <lang>]                  Show all packages details.

chuck@ds418:/usr/bin$ 

bash-4.4# synopkg version PlexMediaServer
1.41.0.8930-72008930
bash-4.4# 

When synopkg is used to install PMS, the PlexMediaServer system internal user is used.

You should use (as example) -
synopkg install PlexMediaServer-version_info_here_.dsm72.spk

dpkg is only being used for version compare logic with the --compare-versions option. synopkg is being used for actual service manipulation.

You can see synopkg being used for stop/install/start here:

If you don’t mind a side-question: Has the distribution.txt file always located at the following location, and has it always contained Plex’s [what I am referring to as] version identifier?

/var/packages/PlexMediaServer/target/Resources/distribution.txt

I’m currently spec’ing it as containing:

DSM 6 to <7 = “synology”
DSM 7 to <7.2.2 = “synology-dsm7”
DSM 7.2.2+ = “synology-dsm72”

But I’ve only noticed it since 7.2.2, so I was curious if its previous existence was an oversight on my part.

@michealespinola

The new package name is a bit different. We had hoped it would wait until DSM 8 but alas it was not to be.

I’m VERY surprised of /root. That should not happen anywhere unless the package has been altered (the username is stored in the package)

I’ve written the package scripting to expect (and require) PlexMediaServer

When Syno creates the user, it sets up:

bash-4.4# grep PlexMediaServer /etc/passwd
Anonx:x:152931:297536::/var/packages/PlexMediaServer/home:/sbin/nologin
PlexMediaServer:x:297536:297536::/var/packages/PlexMediaServer/home:/sbin/nologin
bash-4.4# 

Distribution.txt always contains the target platform package base.

bash-4.4# cat Resources/distribution.txt 
synology-dsm72

Ubuntu Linux is:

[chuck@lizum Resources.2001]$ cat distribution.txt 
debian[chuck@lizum Resources.2002]$ uname -a
Linux lizum 6.8.0-47-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Oct  2 16:16:55 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
[chuck@lizum Resources.2003]$ 

If you want to key off of that, that’ll work.

I’m VERY surprised of /root .

Indeed. I was very hesitant to make this post because I figured it had to be a mistake that I made at some point, but I haven’t been able to otherwise wrap my head around how it may have happened.

I still haven’t deleted it the hierarchy, in case there is something from it could be of use to you.

That actually might prove to be helpful for a different issue, so that’s great news. Thank you!

Does the tool keep any logs to give any indications?

I’m really confused as to how it could have crossed the privilege-elevation boundary (which is obviously dangerous)