Scripted installation of Nextcloud 28 in iocage jail 2018-03-23

[weingeist]

I downloaded it yesterday from github (not git clone but from the website, I doubt that this matters). I attached the script that ran yesterday.


The memory error seemed odd to me too, since I have 64GB on my server. I always wondered why the script only configures half a gig to be used. Well, seems like it doesn't...

Weird thing is, I am not (completely) the only one. @Athers also has the same problem, as discussed (shortly) in his thread.
Do you see any possibilities to increase the output, add some commands before the failing lines for debugging reasons? Or maybe there are some hints earlier in the installation process (also attached). Noticeable:
- Default mac_prefix specified in defaults.json '0cc47a' is invalid. Using '0ec47a' mac prefix instead.
-gpg: Warning: using insecure memory!

 

[danb35]

not git clone but from the website, I doubt that this matters

I'd think git clone would be a simpler way to get it, but a diff between what you posted and what's in the repo shows no differences. In any event, the output of the script looks entirely normal until it gets to running the occ commands. And even the memory limit warnings aren't critical, but they shouldn't be happening. Inside the jail, what's the output of grep memory_limit /usr/local/etc/php.ini?

But the APCu issue is the bigger problem, and it doesn't make much sense--APCu is, I understood, built in to PHP 8.0. Can you post the output of php -i inside the jail?

 

[weingeist]

Memory limit is the same as in the warnings during installation:

Code:

root@nextcloud_23:/ # grep memory_limit /usr/local/etc/php.ini
memory_limit = 512M

I didn't see anything in your script changing this. Is it weird, that 512MB is default?

The lenghty php -i output is attached as a file.

Thank you @danb35 for your support.

 

[mistermanko]

This is supposed to set to 512MB, for reference check the php.ini inside includes folder from the git.
Scanning the install log, it looks like the mount for the includes is not copied as expected, maybe with faulty permissions: /mnt/includes/www-crontab: Permission denied

My theory is after the scripts restarts the jail before installing nextcloud, the mount for the includes either drops completely or gets wrong permissions. That's why the scripts complains about the wrong memory limit, because the php.ini from includes is not copied over, missing apcu_cli and the correct memory limit.

I would - to test this further - make another test_dataset, change the config to the new dataset and a different jail_name. Scrape the dedicated paths like DB_PATH, FILES_PATH etc. from the config and let the script handle it (defaults to $POOL_PATH/nextcloud/db ... etc). I would also as suggested before, make a git clone, rather than download things manually, to make sure the script has access to the includes folder.
See if that works as expected.

 

[weingeist]

Hm, the downloaded script-folder with the includes lies on my user dataset on TrueNAS with user ownership and permissions (you wrote "conveniant location" on github :-D). Could this cause any permission issues? Maybe already earlier in the installation process, some included files were failed to copy.

I will next try to put it in /root and run again.

 

[mistermanko]

It doesn't matter where the script is located as long as it is executable and sits in the same directory with the includes folder and the config. I really suggest to test it with a minimal config (see the github instructions).

 

[weingeist]

SUCCESS!!! Thanks @mistermanko (and @danb35) for pointing out the vital clue for this:

mount for the includes is not copied as expected

Even when not believing in it xD:

It doesn't matter where the script is located

All php-memory limit warnings are gone, and, whats more important, also the APCu memcache errors are gone.

Seems like the script didn't like my script folder in my user data with user permissions:

Code:

root@host:/mnt/vol2/userdata/user1/somesubfolders/nextcloud-script_220324 # ll
total 277
drwxrwx---  2 us    home     15 Mar 24 15:56 includes/
-rwxrwx---  1 us    home  35147 Jan  2 10:44 LICENSE*
-rwxrwx---  1 us    home  39772 Mar 24 21:50 nextcloud_redacted.txt*
-rwxrwx---  1 us    home    468 Mar 24 15:58 nextcloud-config*
-rwxrwx---  1 us    home  23706 Jan  2 10:44 nextcloud-jail.sh*
-rw-rw----  1 us    home  23706 Jan  2 10:44 nextcloud-jail.txt
-rwxrwx---  1 root  home  39894 Mar 24 16:35 nextcloud.log*
-rw-rw----  1 us    home  30903 Mar 25 11:54 php-i.txt
-rwxrwx---  1 us    home  14582 Jan  2 10:44 README.md*
root@host:/mnt/vol2/userdata/user1/somesubfolders/nextcloud-script_220324 # ll includes/
total 239
-rwxrwx---  1 us  home   3761 Jan  2 10:44 caddy*
-rwxrwx---  1 us  home   1009 Jan  2 10:44 Caddyfile*
-rwxrwx---  1 us  home   1047 Jan  2 10:44 Caddyfile-dns*
-rwxrwx---  1 us  home    829 Jan  2 10:44 Caddyfile-nossl*
-rwxrwx---  1 us  home    938 Jan  2 10:44 Caddyfile-selfsigned*
-rwxrwx---  1 us  home     92 Jan  2 10:44 my-system.cnf*
-rwxrwx---  1 us  home     56 Jan  2 10:44 my.cnf*
-rwxrwx---  1 us  home     48 Jan  2 10:44 pgpass*
-rwxrwx---  1 us  home  70741 Jan  2 10:44 php.ini*
-rwxrwx---  1 us  home  46734 Jan  2 10:44 redis.conf*
-rwxrwx---  1 us  home    163 Jan  2 10:44 remove-staging.sh*
-rwxrwx---  1 us  home     68 Jan  2 10:44 www-crontab*
-rwxrwx---  1 us  home  18577 Jan  2 10:44 www.conf*

I can't tell why for sure, since all copy commands seem to be ran as root, not www user. I couldn't tell any differences (using diff) for php.ini, redis.conf and www.conf as well as the Caddyfile between the files copied to nextcloud and the ones in include (except for the obvious placeholders).

 

[mistermanko]

So it was a permission issue in the end. Great that we could solve this!

 

[danb35]

Is it weird, that 512MB is default?

PHP's default is 128M; I change that in the php.ini included in the script. I should probably get around to cleaning up that file and including a header indicating where it comes from.

But I see that @mistermanko has put his finger on the problem. I'm not sure why the problem was happening, but clearly it's resolved now. Do you share that user directory using SMB? If so, are you using ACLs? That might explain trouble mounting it (or copying from it) in the jail...

 

[mistermanko]

I'm still convinced a git clone would have been either helping to mitigate that problem or it would have downright refused to work because of permission/acl issues.

 

[danb35]

I should probably get around to cleaning up that file

So I've done this a bit--I've deleted anything that doesn't change a setting from the defaults. It's still a pretty wordy file, and I may yet delete most of the comments, but it's already quite a bit smaller than it was.

I've also edited the script to halt if copying php.ini fails; I'm expecting this will be a useful proxy for any of the included config files.

 

[weingeist]

Do you share that user directory using SMB? If so, are you using ACLs? That might explain trouble mounting it (or copying from it) in the jail...

Yes, I share over SMB, but no, without any ACL. standard permissions.

I'm still convinced a git clone would have been either helping to mitigate that problem or it would have downright refused to work because of permission/acl issues.

Could be, as I have indeed used git clone when doing it from root. However, the permissions and ownership after copying look mostly the same (except for php.ini, which has 640 in my old failing Nextloud 22, and 644 in the new working Nextcloud 23 instance).

Nextcloud 22 (with error):

Code:

root@host:/mnt/vol0/iocage/jails/nextcloud_22_sandbox/root/usr/local/etc # ls -al php.ini
-rw-r-----  1 root  wheel  70744 Feb 26 14:39 php.ini
root@host:/mnt/vol0/iocage/jails/nextcloud_22_sandbox/root/usr/local/etc # ls -al redis.conf
-rw-r--r--  1 root  wheel  46734 Feb 26 14:38 redis.conf
root@host:/mnt/vol0/iocage/jails/nextcloud_22_sandbox/root/usr/local/etc # ls -al php-fpm.d/www.conf
-rw-r--r--  1 root  wheel  18577 Feb 26 14:38 php-fpm.d/www.conf

Nextcloud 23 (now correctly installed)

Code:

root@host:/mnt/vol0/iocage/jails/nextcloud_23/root/usr/local/etc # ls -al php.ini
-rw-r--r--  1 root  wheel  70744 Mar 25 14:43 php.ini
root@host:/mnt/vol0/iocage/jails/nextcloud_23/root/usr/local/etc # ls -al redis.conf
-rw-r--r--  1 root  wheel  46734 Mar 25 14:43 redis.conf
root@host:/mnt/vol0/iocage/jails/nextcloud_23/root/usr/local/etc # ls -al php-fpm.d/www.conf
-rw-r--r--  1 root  wheel  18577 Mar 25 14:43 php-fpm.d/www.conf

I will run one last test, using git clone from my user data folder (with SMB share), to find out if its the root folder or the git clone that did the trick.

 

[weingeist]

I'm still convinced a git clone would have been either helping to mitigate that problem

I confirm, that running the script (obtained by git clone) but run from the SMB-share dataset works flawlessly. Unbelievable, the hassle caused by downloading from github

 

[danb35]

So the difference is (apparently) that git clone preserves permissions on the files (I know it preserves the execute bit, which was a problem early on), while a .zip file has no concept of file permissions. Pity GitHub doesn't let you download a .tgz, which would likely work as well.

 

[-fun-]

I have a nextcloud jail running which I set up using this script years ago. Nextcloud itself is up to date and at some time in the past I lifted the jail to RELEASE 12.2. However I don't regularly upgrade packages and Caddy is v1.01.

Can I expect pkg upgrade to don't break stuff? Should it be possible to migrate to caddy v2?

The script itself seems to provide a way to reinstall the jail, but can I reasonably expect this to work on a very old installation?

Any pointers are greatly appreciated: I did search the forum but failed.

 

[mistermanko]

I recommend to make a clean install. Make a backup of your nextcloud( stick word for word to the official nextcloud docs), run this script and restore the nextcloud backup. This approach has never failed me until today.

 

[strelok.vc]

After installing nextcloud using a script, I ran into a problem with the ldap_users plugin.
On the ldap setup page, none of the buttons worked properly. I searched for a solution on the internet for several hours and found this article that helped me: https://help.nextcloud.com/t/ldap-ad-integration-nextcloud-18-0-1/73650/8
I’m not sure if this problem is somehow related to the script with which I installed nextcloud, but I decided to write here anyway, because I can’t understand exactly what caused this problem.

 

[danb35]

That sounds like a very broken (and for a very long time) plugin.

 

[strelok.vc]

That sounds like a very broken (and for a very long time) plugin.

I should note that when installing nextcloud from truenas plugins, I did not have such an error. nextcloud version in both cases is 23.0.2

 

[felippe]

I have just installed the latest version of Nextcloud in a TrueNAS jail, using @danb35 's script. It didn't go very promising at the beginning (see below), but, for the time being, my new Nextcloud instance is running pretty well.

Thank you, danb35

Code:

Script started on Fri Apr  1 11:35:50 2022
Command: ./nextcloud-jail.sh
cannot open 'Creating': dataset does not exist
cannot open 'Creating': dataset does not exist
cannot open 'Creating': dataset does not exist
cannot open 'Creating': dataset does not exist
cannot open 'Creating': dataset does not exist
cannot open 'Creating': dataset does not exist
cannot open 'Creating': dataset does not exist
cannot open 'Default': dataset does not exist
cannot open 'configuration': dataset does not exist
cannot open 'missing,': invalid character ',' in name
cannot open 'creating': dataset does not exist
cannot open 'one': dataset does not exist
JAIL_INTERFACES not set, defaulting to: vnet0:bridge0
Fetching: 12.2-RELEASE
[...]