There are two different strategies to access /volume1/@optware through /opt:
- a symlink (the approach I prefer)
- “mount -o bind” (usually run through /etc/rc.optware)
Once in a while (usually after a DSM update)
- the symlink “/opt” got removed
- and/or /etc/rc.optware already executed the “mount -o bind”.
I am checking on my /opt symlink in my ~/.profile, so I notice the misery rather soon.
I am going to describe,
- why I do not like /etc/rc.optware and the “
mount -o bind“
- and how to get rid of the “
mount -o bind” (I hope my approach works!!!)
After you got rid of the “
mount -o bind“, the symlink needs getting re-established:
On synology_apollolake_218+ with x86_64-synology-DSM6.2.4_25556_0 I am doing this:
On … I am doing one of these:
$ ln -s /volume1/@optware /opt …
Why do I not like the “mount -o bind”?
Once it is running, you can not identify, where the mountpoint really points to. The symlink is much clearer.
Why do I not like /etc/rc.optware?
/etc/rc.optware gets run and it already executed these lines:
$ mount -o bind /volume1/@optware /opt # some equivalent to the symlink $ /opt/etc/rc.optware # which in turn runs a couple of init-scripts
I don’t really like the init-scripts runs through
So maybe you (like me) want to prevent
/etc/rc.optware from getting run (and thus also the “
mount -o bind“) by renaming it a little …
How to make /opt/bin available on your PATH
For properly accessing the executables provided at
/opt/bin, you need to extend your PATH like this in your ~/.profile:
For further reading
There is a separate and essential article on “IPKG for Synology”:
Maybe you want to read this file: