Synology upgrade to DSM 6.0

A few notes about the upgrade from DSM 5 to 6

Click to Read More

  • First, stop Plex (as it prevents DSM 6.0 to install)
  • Upgrade to DSM 6.0
  • Upgrade all the required Packages
  • Start Plex
  • Not working anymore:
    • Login in a telnet session as ‘root’
    • ‘homes’ link in /var/services is pointing at /volume1/@fake_home_link
      • open a ssh session as root,
      • do: rm homes
      • and: ln -s /volume1/homes homes
    • Access right to shared folders
      • admin has no access anymore to various shared folders. Ex.: /volume1/homes/admin
      • Go to DSM > Control Panel > User
      • Edit the ‘admin’ account and got the the ‘permissions’ tab
      • Reapply the access rights
    • Web Console.

      • Doesn’t open anymore… It must now be accessed under the web path /webman/3rdparty, via its url: http://hades:5050/webman/3rdparty/webconsole/wc.cgi.
      • I did a new package to start it automatically. See attachments at the bottom of this post. Once installed, open Web Console and change your password (default is “admin”) using the command:  #users modify admin
    • JDownloader (does not start anymore)
      • Java Manager not installed anymore. It is replaced by the new Java package for a more convenient installation procedure.
      • Edit the file to replace “/volume1/@appstore/JavaManager/Java/bin/java” by “/usr/local/bin/java”
      • In that file also change the path to create the pid file into a folder where admin is granted write access !
      • Login into a ssh session and enter the root mode (sudo -i)
      • Execute “rm /var/run/”
      • Check that all files in /volume1/@appstore/jdownloader belong to ‘admin’
      • Exit the root mode
      • Execute “sh start”
      • Check the output in the nohup.out file
    • Filebot does not run anymore
      • Reinstall the “Unofficial Java Installer”
    • FileBot Node does not start anymore
      • Uninstall filebot and filebot-node
      • Uninstall node.js and java 8
      • Delete all the old scheduled tasks related to filebot
      • Delete the input and the output folders (where media files to be renamed are located)
      • Recreate empty input and output folders (as admin – via the File Station, not as root)
      • CTRL-F5 in the browser to fully refresh DSM
      • Install the unofficial java installer of RedNoah + node.js v4
      • Install filebot (version from Package Center) and filebot-node (the version filebot-node-0.2.0-B1-noarch of RedNoah)
      • If it does still not run, test it via a SSH
        • login as admin
        • DO NOT RUN ANYTHING AS ROOT. So, don’t execute: sudo -i
        • cd /var/packages/filebot-node/target/
        • ./start
        • Check the errors returned by this command if any
        • Check also the logs: cat /var/log/messages
      • filebot-node is installed in /volume1/@appstore/filebot-node with
        • a sytmbolic link from /var/packages/filebot-node/target/ and
        • a symbolic link from /usr/local/filebot-node
        • filebot-node schedule a task to run its command /usr/local/filebot-node/task xxx where xxx is the id of a task defined into /volume1/@appstore/filebot-node/data/task/xxx.argsp
    • AcpiOnLan (DSM SSO login not working anymore)
      • the port to access DSM in admin mode (required to do a login via the page /webman/login.cgi) is not anymore stored in /etc/synoinfo.conf with the key secure_admin_port or admin_port respectively for http and https. AcpiOnLan was fetching the port in that file. Instead, AcpiOnLan must now fetches external_port_dsm_https or external_port_dsm_http
    • WordPress
      • After the update of WordPress, as usually, I had to save (although not changed) the current option selected in the “Settings” > “Permalink Settings” otherwise no page was accessible anymore via permalinks (as returned by google search).
      • The automated WordPress update failed to complete. I should have enabled ftp first. I did a manual upgrade.. But the problem was most probably with the owner of the files… (See next)
      • Upgrading plugins didn’t work either… But this problem was solved by executing, as root: chown -R http:http /volume1/web/wordpress





Leave a Reply

Your email address will not be published. Required fields are marked *