It should have gone in the nextcloud-config file, though apparently I haven't yet updated the script to require it to be set. You need to give Caddy an email address, which Let's Encrypt will use to contact you in the event your cert is about to expire (which shouldn't happen), or if they otherwise need to reach you (which would be very unusual). In the jail, runI don't recall any email field. Where would that go?
sysrc caddy_cert_email="you@yourdomain.com"
followed by service caddy start
.It should have gone in the nextcloud-config file, though apparently I haven't yet updated the script to require it to be set. You need to give Caddy an email address, which Let's Encrypt will use to contact you in the event your cert is about to expire (which shouldn't happen), or if they otherwise need to reach you (which would be very unusual). In the jail, runsysrc caddy_cert_email="you@yourdomain.com"
followed byservice caddy start
.
acme.sh --upgrade
acme.sh --cron
Should have been completely expected, as the script tells you about this when it finishes--it obtains certs from the Let's Encrypt staging server by default, to avoid you exceeding their rate limits while you're testing things out. There's a script in the jail that should change the Caddyfile to obtain the cert from the production server instead; runNET::ERR_CERT_AUTHORITY_INVALID. (partially expected)
/root/remove-staging.sh
in the jail to do that.Should have been completely expected, as the script tells you about this when it finishes--it obtains certs from the Let's Encrypt staging server by default, to avoid you exceeding their rate limits while you're testing things out. There's a script in the jail that should change the Caddyfile to obtain the cert from the production server instead; run/root/remove-staging.sh
in the jail to do that.
Don't try anything with acme.sh; that hasn't been part of the jail since I started using Caddy (when NC16 was released).
Edit: See also https://github.com/danb35/freenas-iocage-nextcloud/issues/74#issuecomment-554800584 --if you're having trouble getting Caddy to restart after running the remove-staging script, you may need to make some further edits to the Caddyfile as noted there.
pkg install php72-pecl-smbclient
Code:Starting php_fpm. /usr/local/sbin/php-fpm: Undefined symbol “setproctitle_fast@FBSD_1.5”
root@mediawiki-plugin:/usr/local/etc # service php-fpm start Performing sanity check on php-fpm configuration: [18-Nov-2019 09:16:54] NOTICE: configuration file /usr/local/etc/php-fpm.conf test is successful Starting php_fpm. /usr/local/sbin/php-fpm: Undefined symbol "setproctitle_fast@FBSD_1.5" [18-Nov-2019 09:16:54] ERROR: no data have been read from pipe /usr/local/etc/rc.d/php-fpm: WARNING: failed to start php_fpm
That issue is resolved in the latest version of the script by building php 7.3 from ports.Were you able to resolve the php-fpm issue above?
My first guess would be to install the appropriate version to match the PHP version that's installed, so you'd doWhat should I have done to correctly install the smbclient package?
pkg install php73-pecl-smbclient
.My Nextcloud isn't built using the script, but I've pkg upgraded and hit the same php-fpm issue, in that it won't run with the following error:That issue is resolved in the latest version of the script by building php 7.3 from ports.
Starting php_fpm. /usr/local/sbin/php-fpm: Undefined symbol "setproctitle_fast@FBSD_1.5" [18-Nov-2019 11:23:20] ERROR: no data have been read from pipe /usr/local/etc/rc.d/php-fpm: WARNING: failed to start php_fpm
wondering how you got things working in the script?
cd /usr/ports/lang/php73; make clean reinstall BATCH=yes
Thanks! I've rolled back for now but will give this another go when I have a spare hour.cd /usr/ports/lang/php73; make clean reinstall BATCH=yes
No, it's completely expected behavior, and has been discussed quite a bit in the last page or two of posts on this thread. iX can't get a new release of FreeNAS out before its current version is EOL. This results in ports not building and packages being broken. Sometimes there are workarounds that can be used, which I've done in the script; sometimes you just need to wait until you can build a jail with the current FreeBSD release.Should this be reported somewhere?
No, it's completely expected behavior, and has been discussed quite a bit in the last page or two of posts on this thread. iX can't get a new release of FreeNAS out before its current version is EOL.
That worked to take me to the next step. The ability to add a SMB/CIFS external storage is available now. However, the configuration I try entering and relevant experimental variations seems to all end up with a red circle with a exclamation mark that does not tell me a thing. I am looking for any clue what may be missing. The only thing that seems to be a clue is I try to runMy first guess would be to install the appropriate version to match the PHP version that's installed, so you'd dopkg install php73-pecl-smbclient
.
smbclient -L {hostname}
in the jail and get an error regarding the inability to load an nonexistant smb4.conf file. I am a Samba newbe and so don't know where to go from here. I don't know the service name for samba either. The FreeNAS shell shows sambs_server in services. This round of install has been among the hardest which leads me to think I must have messed up somewhere. Any help would be greatly appreciated.Thanks! I've rolled back for now but will give this another go when I have a spare hour.
I don't think this is a correct statement of what Nextcloud is intended to do. It's intended to share files in the cloud. At its core, it's intended to be the only mechanism by which those files are shared--that's why you need things like the smbclient app or the external_files app to (somewhat) deal with files that are also shared in other ways.Given that Nextcloud is intended to share local network shares in the cloud
pkg install php73-pecl-smbclient
/usr/local/etc/smb[B]4[/B].conf
within the nextcloud jail./usr/local/www/nextcloud/apps/files_external/lib/Lib/Backend/SMB.php
within the nextcloud jail.404 Site 192.168.178.7 is not served on this interface