Server Version#: 1.43.0.10492
DBRepair Version#: 1.14.00
I had some issues where when I entered most of my collections I got the error message “An unexpected error occurred” after doing some googling I saw that people suggested this was likely due to a corruption in the DB. So I downloaded ChuckPA’s DBRepair tool and ran it.
The tool ran fine and did find some errors in the indexes, so I ran a reindex to rebuild it. But now when I try to start the PMS it stops by itself. Looking at the Plex Media Server Log I do find the following error messages:
Feb 28, 2026 12:40:52.713 [140500008876688] ERROR - SQLITE3:0x80000001, 14, cannot open file at line 41714 of [a29f994989]
Feb 28, 2026 12:40:52.713 [140500008876688] ERROR - SQLITE3:0x80000001, 14, os_unix.c:41714: (13) open(/volume1/PlexMediaServer/AppData/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db) - Permission denied
Feb 28, 2026 12:40:52.713 [140500008876688] ERROR - Promise destroyed without handling exception: Promise fell out of scope without resolving or rejecting
That indicates a permission issue, but when I look at the permissions for the PlexMediaServer shared folder the admin user still have read/write access and the internal user PlexMediaServer does also still have read/write access.
Any ideas what is then causing the permission denied issue that stops the PMS from running?
Logs.zip (1.6 MB)
Open File Station on the NAS and right click on the PlexMediaServer folder and select Properties.
On the Permission tab, highlight PlexMediaServer and click on Edit.
Make sure ALL permissions have been granted and click on Done.
Then enable Apply to this folder, sub-folders and files Important! and then click on Save.
The process will take a while to complete, so be patient.
Hmm, Interesting.
All permissions were showing as turned on as it should. So I tried removing all permissions, then press Apply. Then readded all permissions and hit Apply again and now it is running.
So it seems the UI was showing that all permissions were given, but something had been turned off somewhere.
The UI only shows so much and File Station is NOT strong on showing folder/file permissions.
To see the actual permissions you must use the CLI (ssh) to view the permissions for each individual folder/file.
The ls command will display the Linux permissions, but you need to use the synoacltool command in order to view the Windows ACL’s for each file.
Since the PlexMediaServer folder is a shared folder, it uses Windows ACL’s by default.
Welcome to Synology and in case you are wondering, the founders of Synology are Ex-Microsoft … lol
This is why you must follow the procedure I outlined above in order to set the permissions correctly En Masse.
During the procedure, if you forget to enable Apply to this folder, sub-folders and files then you are just wasting your time as your efforts will achieve nothing.
That is the one option that sets the permissions for all files and folders and the reason it can take so long to complete as it sets the permissions for every individual folder/file.
NOTE:
This error happens on Synology when DBRepair is not run as user root.
Running as an “Administrator” / “Administrative User” is NOT sufficient.
On Linux, only user “root” can set the correct permissions after DB work is complete.
@ChuckPa
DBRepair complains when it is NOT run as ‘root’, so I don’t think that is the cause in this case.
I have had this happen also, when the DB files are moved into the correct location, the permissions are lost, scrambled or simply do NOT inherit.
I don’t believe this is a fault with your script, we have seen this happen in other ways also, so I think it’s just a quirk of Synology DSM.
@trumpy81
This isn’t a DSM fluke, It’s evidence someone / something poked around in the PlexMediaServer shared folder without being root
In DBRepair.
# Work in the Databases directory
cd "$DBDIR"
# Get the owning UID/GID before we proceed so we can restore
Owner="$(stat $STATFMT '%u:%g' $CPPL.db)"
Perms="$(stat $STATFMT $STATPERMS $CPPL.db)"
It gets the permissions of the running PMS before doing anything.
It creates the new DBs as part of its work.
When it moves the new DBs into position, It restores the permissions it obtained
# Set owner and permissions
chown $Owner $CPPL.db
chmod $Perms $CPPL.db
Regret to disagree but it can’t work flawlessly on countless Linux/DSM/QNAP systems and fail – blamed on DSM.
Sorry, Don’t buy it.
1 Like
Thanks for the info on this and how the script works.
