Please log a bug against the snap and we can troubleshoot over there.
I have an issue with using Apache to proxy to the Nextcloud Snap. As far as I know, when setting up the proxy via virtualhosts I need to know the documentroot for the Nextcloud Snap which I cannot seem to find. Any advice or sample proxy setup config? Can’t seem to find any info on the nets with using a proxy to a snap.
Fresh install of Nextcloud snap (13.0.2) on Ubuntu 18.04. I have a Dev server and a production server. On the Dev server, I enabled server-side encryption and clicked to encrypt the local storage. Logged in with a user, created a txt file and confirmed on the FreeNAS backend that the file content is encrypted. Because encryption is only for new / modified files, that would not fit for the production server.
I followed the procedure to get the module to encrypt all files with the occ command. The procedure says to put server in maintenance mode before running the encryption.
1-I needed a fix to put the Nextcloud in maintenance mode
The occ command is not enough and a restart of php-fpm is required for entering / leaving maintenance mode.
2-Once in maintenance, the command failed
It complained that, because of the maintenance mode, no module was loaded. That included the encryption module that was not loaded. Indeed, an occ command to list all encryption modules returned an empty list.
3-Did work out of maintenance mode
Put back the Dev server out of maintenance mode and re-run the encrypt-all command. It worked and retro-actively encrypted all existing files (very few because it is test only).
I can not do that on the production server. Encrypt-all must work while in maintenance mode…
Commands involved :
nextcould.occ maintenance:mode --on
snap restart nextcloud.php-fpm
Sorry if this is misplaced, I can’t track down my SSL certs. I’ve googled and looked where they’re saying they are and can’t find them. I need to copy (probably symlink) to them for my bitwarden server on the same domain. I installed it using the
sudo nextcloud.enable-https lets-encrypt option.
No tuning of Apache, PHP or MYSQL configurations
For example PicoCMS can’t work with a snap install as it requires Apache config changes
I recently started experimenting with Nextcloud. I’m running Nextcloud 13.0.6snap1 on ubuntu 18.04 base, with MYSQL database and S3 Object storage
I’ve noticed that using a snap I see the following things
Occasional apache user errors,
[unixd:alert] [pid 26374:tid 140264660563840] AH02155: getpwuid: couldn't determine user name from uid 4294967295, you probably need to modify the User directive
Stack trace: #0 /snap/nextcloud/8971/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect() #1 /snap/nextcloud/8971/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion() #2 /snap/nextcloud/8971/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform() #3 /snap/nextcloud/8971/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(623): Doctrine\DBAL\Connection->getDatabasePlatform() #4 /snap/nextcloud/8971/htdocs/lib/private/DB/Connection.php(151): Doctrine\DBAL\Connection->setTransactionIsolation(2) #5 /snap/nextcloud/8971/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct( in /snap/nextcloud/8971/htdocs/lib/private/DB/Connection.php on line 64 [26-Sep-2018 13:53:43 UTC] PHP Fatal error: Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000]  Connection refused in /snap/nextcloud/8971/htdocs/lib/private/DB/Connection.php:64
- Adding multiple tags on files that were opened recently causes the the a long CPU spike in mysqld and php-fm processes, reproducibility 80%
I’m getting the following error message on Nextcloud Box v13.0.7.
ResourceLocator can not find a web root (root: /var/snap/nextcloud/9570/nextcloud/extra-apps/calendar, file: index.php/css/calendar/e34c-ec1a-app.min.css, webRoot: , throw: true)
and also calendar sync stopped working on one phone (SailfishOS) but not the other (Android). First I thought the issue was with SailfishOS, but now I’m not so sure, since a delete & re-add of the calender did not make any difference. And when I saw the above mentioned error message I also noted that the Nextcloud version is 13.0.7 and started wondering, could an update have caused the failed calendar sync?
I’m on a raspberry pi b3
it’s running raspian (I think it’s debian stretch or something like that)
Everything was going just fine until i was prompted by webpage updater to update to 13.07.
After updating (by clicking ‘update’ in web updater) all access to NC died, including access by client on desktop
I can access the box no problem via ssh, however, the rest is dead.
I have tried:
- purging snapd
- removing/reinstalling nextcloud snap many times, using different channels like --edge
- I did sudo rpi-update
- I also did sudo apt update in main OS
I have this issue too:
So I did this:
- changed from this in root.ini
and changing to this:
(didn’t fix that issue either).
I’m totally lost. I have white screen of death if I try to access box from .local or via web.
One very interesting thing to me is that I cannot do the nextcloud.occ commands at all
I really wanted to try this one:
If I start typing them and press tab, the system knows they are there and autofills. But even if I use SUDO or even sudo -s to try to execute the command it returns a ‘command not found’ message. This is very strange to me.
I’m willing to try whatever at this point.
My only next step is a complete re-install but i didn’t back up files of user stuff so the pain of this will be large. I’m willing though…
Thanks very much folks.
It’s great that LDAP is supported in the SNAP install, but a huge oversight that it is not possible to specify a private root certificate.
Word to the wise: I committed a serious error in snap, and here’s what I did to come back from it.
I originally installed Nextcloud 14 from the 14/candidate channel with the command:
snap install --channel=candidate/14 nextcloud
Then I wanted to see if any security updates could be had by trying to refresh the snap manually, not understanding that these updates (called “Auto-Refreshes”) happen automatically! With snap, there is no such equivalent to “apt-get update && apt-get upgrade”.
So I stupidly ran the command:
snap refresh --stable nextcloud
…which effectively downgraded my Nextcloud 14 to 13 (and the snap command doesn’t tell you what the before-and-after versions of Nextcloud are, it just successfully completes the command, with rather poor verbosity)! I was not warned that I was effectively about to do something stupid, namely the downgrade from 14 to 13 (and I would have appreciated a suggestion that I might want to cancel that idea before continuing on). Then Nextcloud was left totally unusable. So next I ran the command:
snap revert nextcloud
…which reverted back to 14. Then Nextcloud worked again as before. Whew! But I was not out of the woods yet. Then snapd’s “Auto-Refresh” feature “helpfully” “upgraded” me back to 13, not long after (as the “channel” was still set to “stable”)! So Nextcloud magically stopped working again. I wanted to strangle Mark Shuttleworth very badly at that time!
So I ran the command:
snap install --channel=candidate/14 nextcloud
…again, to try to set the channel back to 14/candidate. Sorry, no can do, as it’s already installed!
Here is the magical command which fixed it all. After doing another “snap revert nextcloud” (to get back to 14) you have to run:
snap switch --channel=14/candidate nextcloud
Also helpful were the commands:
…which revealed that the “Auto-Refreshes” were happening (which kept automatically downgrading my Nextcloud to 13, behind my back), as well as:
snap list --all
…which showed me how I had both Nextcloud 14 and 13 installed at once (and 14 got “disabled”, and could be potentially be reverted to, after a downgrade to 13). It was here where I eventually realized I needed to get the “Tracking” column to be set back to “14/candidate”, not “stable”, for the “nextcloud” line.
I also removed the disabled Nextcloud 13 snap (as a final cleanup step) with the command:
snap remove --revision=9868 nextcloud
How did I know that Rev 9868 needed to be removed? Because that was the “Rev” listed for Nextcloud 13 in the “snap list --all” command.
I see the following error message in my logging app (in the setting) several times a day:
ResourceLocator can not find a web root (root: /var/snap/nextcloud/9868/nextcloud/extra-apps/spreed, file: index.php/css/spreed/73df-4cab-autocomplete.css, webRoot: , throw: true)
I have the following snaps installed on my server
$ snap list Name Version Rev Tracking Publisher Notes core 16-2.36.1 5897 stable canonical✓ core nextcloud 13.0.7snap2 9868 stable nextcloud✓ - spreedme 0.29.5snap1 22 stable nextcloud✓ -
What if we want to use Nextcloud Talk within a Nextcloud snap, complete with a coturn TURN server?
I have questions about using a turnserver (coturn) with the Nextcloud snap, on the same server (this is to try to get Nextcloud Talk working the best). Has anyone done this before? If the Nextcloud snap were to talk to the coturn server, wouldn’t that need some special port “plumbing” added to the snap, to enable the intercommunication between the two?
Furthermore, if one wants to use SSL with the coturn server, then one will want to use the certbot SSL certificate files (cert.pem and privkey.pem) that got generated within the snap, but the pathname leading into the snap is not necessarily a constant thing (or is it?), as it’s got an integer that might change, as the snap periodically upgrades itself. For example, my nextcloud lives within:
It’s kind of sounding like the coturn server needs to be on a different server than the Nextcloud snap, and have it’s own ssl certificate. Or maybe coturn itself eventually could be bundled into the snap, in case users want to use Nextcloud Talk with their snap.
HowTo: Setup Nextcloud Talk with TURN server
Snap or not should not make a difference.
Note that Nextcloud Talk and the TURN server do not talk “directly” each other. The users WebRTC clients (e.g. browser, Android app) use the TURN server information from Nextcloud Talk settings to connect remotely to coturn. So as long as both are reachable from the web, it’s fine.
Of course if you have coturn within snap, it needs to be reachable via chosen/configured port. Since I never used snap, you know better than me how to make it listen to/forward a certain port.
A non-snap coturn accessing SSL cert within snap sounds wrong to me. You already mentioned the issue with non-constant path. I suggest you either find a coturn snap then, or create cert files outside of snap.
Fairly recently certbot has gained the ability to do wildcard SSL certs (thereby allowing two SSL certs for the same Nextcloud server, the coturn server using a domain name like “turn.yournextcloudserver.com”), however this doesn’t seem to be packaged nicely for Debian 9 yet. A second SSL cert for the coturn server could perhaps be generated using this obscure howto (but I’ve never tried it).
You can as well simply duplicate the certs from certbot. Just needs to be redone, when they are renewed.
AFAIK, self-signed certificates work as well. But not 100% sure if all browsers and such connect well then without complaining about the non-trusted cert.
I’m in Gallery Slideshow/Preview Generator app trouble on my Nextcloud 14/stable server. Please see here for more info.
In summary, I can’t figure out how to properly run the “Preview Generator” app’s “/snap/bin/nextcloud.occ preview:generate-all” on the command line…
Edit: I merely rebooted the server, and it all seems to work OK now.