I have a few LinkStation units which all react in the same fashion with OptWare installed.
LS220DE/421DE/etc.
[1]
Once installed, the web interface and optware conflict regarding Samba - when adding a new shared folder AFTER optware is in, the folder is created in /opt (instead of say Disk1) and the config files (/etc/melco/*) relating to Samba's setup also point to /opt instead of disk1, array1, etc.
It seems as though the LS units "detect" shares based on their raid based mount points (ie: md101 for disk1) and when rc.optware launches, it's creating a bind-mount which ALSO takes on md101's ID, thus LinkStation thinks that's where the folders/shares go.
In order to correct this I've created another .optware directory under /mnt/.optware (which binds to md0 or / instead of md1) and linked all of the contents (folders) within the /mnt/disk1/.optware/ onto /mnt/.optware/* which thus far is working like a charm. A script in /opt/etc/init.d launches at boot to re-check the links in case new extensions were installed that created files/directories not already linked in.
[1b]
On the same note, since most multi-drive LSPro units have the option for Raid 0/1, the bootstrap script should detect whether to use disk1 or array1 - easy enough to do, if [ -f /mnt/array1/,accesstest ]; then that's the directory to install into. When using Raid, optware gets lost otherwise.
[2]
In case it matters to someone out there, nfs-utils extension under cs05q3armel is broken. Compiler flags I'm guessing.
nfs.sh: line 19: 20114 Illegal instruction /opt/sbin/nfsd
I have a few LinkStation units which all react in the same fashion with OptWare installed. LS220DE/421DE/etc.
[1] Once installed, the web interface and optware conflict regarding Samba - when adding a new shared folder AFTER optware is in, the folder is created in /opt (instead of say Disk1) and the config files (/etc/melco/*) relating to Samba's setup also point to /opt instead of disk1, array1, etc.
It seems as though the LS units "detect" shares based on their raid based mount points (ie: md101 for disk1) and when rc.optware launches, it's creating a bind-mount which ALSO takes on md101's ID, thus LinkStation thinks that's where the folders/shares go.
In order to correct this I've created another .optware directory under /mnt/.optware (which binds to md0 or / instead of md1) and linked all of the contents (folders) within the /mnt/disk1/.optware/ onto /mnt/.optware/* which thus far is working like a charm. A script in /opt/etc/init.d launches at boot to re-check the links in case new extensions were installed that created files/directories not already linked in.
[1b] On the same note, since most multi-drive LSPro units have the option for Raid 0/1, the bootstrap script should detect whether to use disk1 or array1 - easy enough to do, if [ -f /mnt/array1/,accesstest ]; then that's the directory to install into. When using Raid, optware gets lost otherwise.
[2] In case it matters to someone out there, nfs-utils extension under cs05q3armel is broken. Compiler flags I'm guessing. nfs.sh: line 19: 20114 Illegal instruction /opt/sbin/nfsd
Thanks!