Ok, I’m trying to get some more control of owncloud (specifically getting rid of it - it is not required and takes up too much space, users do not want or need it)
So: went to the documentation at ownCloud Documentation
According to the docs
sudo -u www-data php occ -V
simply should give the version number.
Could not open input file: occ
I get the same with all the commands listed and even from within /home/user-data/ownCloud
as there seems no admin panel how can we admin this monster?
Hi stegan,
Make sure you do “cd” into the “/usr/local/lib/owncloud” and then execute the command:
root@box:/usr/local/lib/owncloud# sudo -H -u www-data php occ -V Nextcloud version 12.0.3
Some other usefule directories and files that you may check as well:
/home/user-data/owncloud-backup /home/user-data/owncloud /home/user-data/owncloud/owncloud.db /home/deploy/mailinabox/setup/owncloud.sh /home/deploy/mailinabox/tools/owncloud-restore.sh /home/deploy/mailinabox/tools/owncloud-unlockadmin.sh /usr/local/lib/owncloud
Cheers,
Martin
Many thanks Martin
So simple really, just needed to be in the right place 
Thanks for the other pointers. I’ll have a dig around and see what else can be killed off from this completely unwanted (by us) ownCloud. I’m guessing but any MIAB upgrade is going to undo any changes (which is always a fallback should I blunderbus the whole system.
Have a good rest-of-the-weekend
Hi stegan,
I found NextCloud really beneficial, and I’m not just talking about provisioning of “calendar” and “contacts” to your current e-mail users but also when I’m sending larger files I use it to upload the file/folder and create a share link ( could set password and expiration dates as well), so I only send the shared link to my e-mails.
I was thinking just the opposite, next cloud has an app for e-mail integration when this app matures enough I would ditch roundcube altogether and move to use only /cloud. Me and most of my users are using e-mail clients and they rarely use the WebMail interface.
But If you want to disable it then you head on to the right direction this is option one - to disable it on app level.
Option two - I would look into Nginx config in /etc/nginx/conf.d/local.conf under # Nextcloud configuration.
Make a copy and do some testing:
I’m not very familiar with Mail-in-a-Box structure and at that stage, if you disable it may cripple mail-in-a-box and may produce unwanted results.
Yes, rerunning “mailbox” or an upgrade will overwrite the changes.
Have a good weekend too!
Martin
I understand your perspective and it is likely to be the same as most of those who turn to MAIB as a mail solution.
Our corporate mail requires all those sort of assets and is not my responsibility or concern.
To give you, and possibly others, some idea of my perspective/involvement:
I am working on a client’s project.
They have no interest in Roundcube, ownCloud, or any fancy user interface with their mail server. All they want is an owned, core, secure, simple to maintain, lightweight, backend to very small, multiple mail accounts. They will only be dealing with small emails, mostly in plain text, with no attachments. They require spam filtering and are expecting, who doesn’t, to get a fair amount of that. They require no backup of email. but do require system backup and updates. They expect a ratio of about 15:1 of genuine traffic in:out.
MIAB appeared to be the easy option for me and them. All their interaction with the backend will be through their web site and their own interface.
MIAB has been a very simple install from my perspective and literally only a few hours from install to working system (LOTS of praise to the team for that!) I now need to just clip its wings and fix some inter-operability issues.
Thanks once again
Okay, now I understand your objective.
Yes, MiaB really saves time in the deployment of the efull mail server, it’s a great also becausee it has simple API interface. I’m still learning how all bits are connected under the hood but agree MiaB it’s great mail-server.
Are you going to use NS functionality of MIAB? Will this company host it on its own infrastructure or in the public VM?
I was thinking of doing something similar as a stripped down MiaB on a secondary server in another geo-location running only some of the services as a relay / live backup /redundancy, but I’m still chewing it.
Once you’d figure all bits would be probably good to make a branch of MiaB git and apply your changes then pull the update from your GitHub and update from there. Testing it on a VM before applying it to production would be a fit. I sow somewhere pointing out to a script that can do an actual test of the services if they function fine, that can be adopted and aid your testing.
Would be glad to hear your solution whenever you are ready.
Regards,
Thanks for taking an interest.
Setup is main site on a separate domain on its own dedicated server, Mail (and little else) on its own DO droplet with static page redirecting (for now, 'cause that is simple) and works, back to the main site.
Current issues are:
Actually those issues are other way around. As I am doing 1 to work-around 2 whereby a PHP script returns the result of a PHP curl from the main server.
Just posted a separate topic on (1) and already have one on (2)
So with MIAB you HAVE to reference the full URI to the PHP script:
Examples:
https://box.example.com/index.php
https://box.example.com/index.php/wp-admin
etc etc.
If you want to be able to use PHP without that (were the server will assume index.php is what needs to be loaded) change the indexes options in /etc/nginx/conf.d/local.conf from
index index.html
to
index index.html index.php
Do that for each site you want index.php to be the default index (like how index.html works)
Note: this will REVERT every time you update DNS or add a new email address, or if you update MIAB.
The simplest solution is to use 1 VM for MIAB ONLY, and another for apache & PHP (or NGINX and PHP if that’s your thing).
Hope this helps mate.
Yes that REVERTING is a real pain! Especially as it effectively removes the option of using even one static site with PHP using the MAIB server! 
I don’t quite see why this is done. The static pages “should” be outside the mail server as they have little if anything to do with it. Hey, but I guess there must be some reason 
The simplest solution
Well that is just what was originally planned. Now having solved the other problem of access to the mail API from the webserver on another box, I hopefully no longer need to run PHP on the MAIB server. Now to get IMAP working on the webserver box…
Thanks all for your help and advice, your time appreciated.
To be fair with you on this friend, Mail in a box is a very specific appliance for specific needs.
MIAB is for Mail, Cloud Storage, and Static HTML web sites. that’s it, running PHP on it is unsupported.
For PHP imap:
apt install php-imap (Assuming you are on a debian based distro)