It seems that might help avoid all this mess (waves arms wildly). And since we’re single-digit days away from “the masses” getting DSM7, I’d say that’s a wise, wise move to implement ASAP before there’s about a zillion people in the same boat I was in earlier today (just updating DSM and presuming everything will work, especially since the DSM installer doesn’t identify Plex as a “problematic” package).
Dave,
I’m going to update the DSM 6 installer to minimally re-assert ACLs for all files in the Plex shared folder.
I know there will be those who complain but I think this experience provides adequate justification for taking the action.
Those who will become revision locked on DSM 6 won’t care.
Those who eventually migrate to DSM 7 will be grateful it was done.
Implementation of this won’t be pretty as I will have to launch the find - exec with each DSM 6 update installation and run in the background.
NOTE:
As I stated in the Preview Thread & Migration Process posts,
the biggest reason it takes time to perform the actual migration is:
- For all metadata files which are symbolic links, convert hard paths to relative paths.
This is required for transcoding to work correctly when playing Extras.
1 Like
Makes sense to me (if that matters! 
). I did note that even after doing all this I still can’t “customize” permissions inside DSM on my Plex share. I realize that doesn’t matter since I’m already migrated over, but I find it … interesting. 
Thanks for the help today, @ChuckPa. Hopefully this avoids others from having to spend their afternoons doing this next week!
Dave,
If the “Customize” button was gone , but the migration ran normally, then it doesn’t matter if you needed change it or not.
What is important is that all the files in the existing installation were migrated.
I wish DSM 7 afforded me the option to conditionalize the menu.
If I could I would display:
* Migrate existing DSM 6 Plex installation
* Ignore existing installation and start fresh.
but I can’t . The GUI is a static JSON file. 
CAVEAT:
In DSM 6,
- User
PlexMediaServerdoes not yet exist. - I cannot create it prior to DSM 7 installation else DSM 7 will rename the username and invalidate the ACL.
- I’m going to open the ACL to be even wider if I can.
I need to speak with my management about allocating time for this effort given the current status of DSM 7.
I haven’t jumped onto the Beta/RCs but I expect I will be updating to DSM7 at some point - maybe the final release or more likely first patch after that when they properly fix things.
I’ve been following the PMS/DSM7 threads over the past weeks with interest as when I do update DSM I want to be confident in knowing what steps should be followed to upgrade PMS successfully from the current 6.x.x version.
If what you are suggesting here would ease that process and/or remove potential sticking points where things may go awry then that is something that I’d personally appreciate.
Yes, WAIT.. WAIT as long as you can.
- DSM 6 is stable and works.
- DSM 7 is unknown
Most importantly
The same PMS version (same binary package actually) runs on DSM 6 as it does on DSM 7.
You are not missing out on any features.
2 Likes
Makes sense, and thank you!
One idea I had: at some point during yesterday’s trials, I had the /volume1/Plex folder owned by PlexMediaServer user, and yet the Plex installation/upgrade would still fail with the static permissions message. This was frustrating since I knew it would work. But your script was looking for ACLs, which didn’t exist on my system, so I went in with synoacltool and dealt with that.
But I wonder … if your script looked for the linux folder owner and its permissions, too, that might be another way to have freed this up and solved for users who can’t (easily) adjust ACLs but could adjust folder ownership.
In the end what I did was to attempt to start the Plex installation while my find - exec command was still running. I know that’s not a good idea, but I felt confident that PlexMediaServer had the rights to do what it needed to do. In the end, it all worked, even though I took a semi-dangerous path.
It doesn’t matter if I look at it or not.
As the non-priveleged user PlexMediaServer , I am powerless to do anything.
chown requires root.
Oh… I meant that since I had already gone in as root and chown’ed the /Plex folder (recursively), PlexMediaServer had the necessary rights via linux permissions, just not via ACLs. It’s just that the installer didn’t look at that and (therefore) didn’t know it had equivalent rights.
I can’t ask everyone to do what you did.
Some are lucky to click “Manual Install”, upload the package, and click “OK”.
1 Like
If I could have done what you did from the script…
I’d have done it already and this discussion would not have happened because installation would be as painless as DSM 6
1 Like
Right, no… I grok this. What I’m saying is that I got to a point yesterday where I knew it had the permissions it needed, but your script was only looking for ACLs and therefore failing even though it would’ve worked.
My pass with synoacltool was (effectively) an academic one so that your test would pass. My thought (aka suggestion? 
), would just be to put another test in: if /Plex is owned by the appropriate user, pass and run the rest of the script.
ACL is the ONLY thing I can look at – BECAUSE
DSM7_migration _tool:
- Repairs all symbolic links from broken legacy metadata agents.
- performs the chown in the one context which is allowed on DSM 7
- Performs the final move of the data
- Cleans up the Plex shared folder.
I recommend you look at dsm7_migration_tool and all which is happening there.
Now, look at what is required for that script to run without error in ALL cases.
You will find
- Check the ACL
-or- - Wait for an hour to exhaustively check all files to see if they comply with permissions.
The scope of this problem, as it pertains to all the users, is quite large with a huge variety of things people have done to customize their PMS (root of the problem) over the years.
There is a whole lot more scope to this problem than you’ve seen so far.
1 Like
Ahh, gotcha! Thanks for this, and yep… makes sense.
I ran into this with some other packages, too, of course… and moved all of those to Docker containers with great success (and a lot less time invested). I realize Docker isn’t for everyone, but in looking back on this, migrating Plex to Docker would likely have been hours faster for me yesterday… and potentially prevent problems like this from cropping up in the future.
Docker is always easier on Synology.
You have “ROOT” privilege.
1 Like
I updated to the latest (Plex Pass) version on the site. And now I was able to specify the log location on my external drive!
unfortunately it did not work for me… 
I have the Synology DS420j with DSM 7.0-41882
I tried many versions of installations but I always get the same error:
“The operation failed. Please sign in to DSM again and retry.”
are you familiar with this error?
Yes, that is easily remedied.
What’s happening is:
-
DSM has an ‘authentication timer’ built into it.
-
It is supposed to sign out your session when that expires.
-
Both DSM 6 and DSM 7 don’t always sign you out (web session) when that happens.
-
You’re left in the state where;
a. Signed in
b. Can interact with most of the NAS / DSM
c. Can’t control any of the packages
Solution:
-
Sign out and back in. If not resolved, Restart DSM.
-
Preventing / forestalling it as much as possible in the future:
a. IF you don’t have security concerns about someone grabbing your desktop session (use the computer when you’re not looking)
b. Control Panel - Security - General (tab)
c. Set the idle timeout value to65535minutes (45 days)
Why is DSM 7 still being considered as instable? As I understand it, DSM 7 final will be released tomorrow (29th June) and will be identical to the RC release. It doesn’t seem like any changes are going to be made to the packaging that were mentioned previously.
Given this, surely builds can now continue again? Or am I missing something?
Why is it considered unstable ?
-
DSM 7.0-40000 was given to us to start DSM 7 development.
-
DSM 7.0-41222 was released as BETA and we completed development using it.
-
DSM 7.0-41882 was released as Release Candidate
a. INFO file allowed contents changed – breaking our packaging.
b. Shared Folders app “Custom” button changed – breaking our migration procedure -
DSM 7.0-XXXXX will be released,
a. INFO file allowed contents will change AGAIN.
b. “Custom” permissions button will change AGAIN.
c. There are other changes coming.
We communicate with Synology a couple times every week.
While I welcome the communication and am grateful for it, we are not told everything which will be coming in DSM 7.
2 Likes
