[Support] Linuxserver.io - Nextcloud

[CHBMB]

Yes

[yukonhijack]

Thanks!  Got it to work, and now the apps work on my iPhone, Macbook and iPad!

[peter_sm]

Anyone that know how to change the upload limit? Even if I did changes on the Admin-Additional settings it still don't change the settings from 500MB !

 

//Peter

[CHBMB]

Anyone that know how to change the upload limit? Even if I did changes on the Admin-Additional settings it still don't change the settings from 500MB !

 

//Peter

 

Worked in the webui for me...

[peter_sm]

Hi, Actually it change the settings on the website but it will not let me upload large files. I will take a closer look at the errors I get tomorrow.

[CHBMB]

Hi, Actually it change the settings on the website but it will not let me upload large files. I will take a closer look at the errors I get tomorrow.

 

OK, well I set a limit of 2TB and I just checked by uploading this..

 

[tazire]

Do we still use your instructions on updating to the latest version from the first post?

[CHBMB]

Do we still use your instructions on updating to the latest version from the first post?

 

Yes, although the version number has changed.

[tazire]

Do we still use your instructions on updating to the latest version from the first post?

 

Yes, although the version number has changed.

 

Cool was thinking that alright. Is this something that will come with future updates? or will that be down to the developers of nextcloud?

[CHBMB]

Do we still use your instructions on updating to the latest version from the first post?

 

Yes, although the version number has changed.

 

Cool was thinking that alright. Is this something that will come with future updates? or will that be down to the developers of nextcloud?

 

We update the base image, but when there's an update on top of that (ie once you've installed it) then at the moment you have to follow the instructions I posted.  The problem comes from making user files persistent in /config  and not overwriting config with the update.

 

FWIW the instructions I posted are a recognised way of updating Nextcloud and posted on their site, so not really going off piste....

 

https://docs.nextcloud.com/server/9/admin_manual/maintenance/upgrade.html

[tazire]

Do we still use your instructions on updating to the latest version from the first post?

 

Yes, although the version number has changed.

 

Cool was thinking that alright. Is this something that will come with future updates? or will that be down to the developers of nextcloud?

 

We update the base image, but when there's an update on top of that (ie once you've installed it) then at the moment you have to follow the instructions I posted.  The problem comes from making user files persistent in /config  and not overwriting config with the update.

 

FWIW the instructions I posted are a recognised way of updating Nextcloud and posted on their site, so not really going off piste....

 

https://docs.nextcloud.com/server/9/admin_manual/maintenance/upgrade.html

 

I wasnt questioning your tutorial m8. Just currently getting the update core version and I was considering just holding off if i thought an auto update was something that wasnt too far off. Ill prob update using your tutorial soon enough. thanks

[CHBMB]

I wasn't offended, just attempting to reassure you that's all.  Wanted to make it clear it wasn't some hare brained idea of mine to update using that method.

 

Sent from my C6903 using Tapatalk

 

 

[KingB]

Hello,

 

I am using your latest docker Container and it seems to work fine at first. I was able to upload all my content from my main desktop to the Nextcloud out of my Nextcloud Folder (10GB)

 

Sync works fine with that pc.

 

But now I want to sync all the stuff inside my laptops nextcloud folder.

 

I constantly get the following error in the logfile and in the client I just got the message in red, operation canceled.

 

2016/11/12 11:00:15 [crit] 305#0: *307 open() "/var/lib/nginx/tmp/fastcgi/1/00/0000000001" failed (13: Permission denied) while reading upstream, client: xxxxx, server xxxxx request: "GET /remote.php/webdav/xxxx

 

Now I ssh'ed  into the docker container to see if there is an permission error with the tmp folder.

 

I changes to whole tmp directory to 777, no change.

 

The default user and group is abc? Is that correct?

 

Because i changed it to nobody and nogroup and then the sync works and the files download correctly.

 

But this time the whole nginx directory insde the /var/lib folder.

 

I think this is not correct way to fix it, because i have no big security problems i guess?

 

Any advice?

 

 

[CHBMB]

No advice.  You've done so much before you posted, I'm not even going to try and unpick it all.

 

User and group are abc which have uid and gid of 99:100 which is the same as nobody users.

 

 

 

 

Sent from my C6903 using Tapatalk

 

 

[KingB]

Ironie ?

 

So it is not a security risk, if the owner is set to nobody:nogroup instead if abc, which would be the same?

[CHBMB]

Ironie ?

 

So it is not a security risk, if the owner is set to nobody:nogroup instead if abc, which would be the same?

 

Unraid by default uses nobody:users not nobody:nogroup

 

OK, explanation. 

 

Default inside a container is everything runs as root.  Problem is things that end up in mounted folders like /config /downloads /whatever then appear to the host that the permissions aren't compatible.

 

So we create a user abc, group abc and these inherit the uid and gid that is set in the template (99 & 100) equal to nobody:users, this ensures the files created are compatible with the host.

 

To  illustrate:

From within the container:

root@tower:~# docker exec -it nextcloud bash
root@ee0c2bb53f10:/$ cd /config
root@ee0c2bb53f10:/config$ ls -la
total 0
drwxrwxrwx 6 abc  abc   69 Jul  6 11:55 .
drwxr-xr-x 1 root root 206 Nov 12 01:19 ..
drwxr-xr-x 2 abc  abc   48 Jul  6 11:55 keys
drw-r--r-- 3 abc  abc   18 Jul  6 11:55 log
drwxrwxr-x 3 abc  abc   77 Jul  6 11:55 nginx
drwxrwxr-x 3 abc  abc   51 Oct 12 16:02 www

root@ee0c2bb53f10:/$ id abc
uid=99(abc) gid=100(abc) groups=100(abc),1000(users)

 

From the host:

root@tower:~# cd /mnt/cache/.appdata/nextcloud/
root@tower:/mnt/cache/.appdata/nextcloud# ls -la
total 4
drwxrwxrwx  6 nobody users   69 Jul  6 11:55 ./
drwxrwxrwx 35 nobody users 4096 Nov 10 21:24 ../
drwxr-xr-x  2 nobody users   48 Jul  6 11:55 keys/
drw-r--r--  3 nobody users   18 Jul  6 11:55 log/
drwxrwxr-x  3 nobody users   77 Jul  6 11:55 nginx/
drwxrwxr-x  3 nobody users   51 Oct 12 16:02 www/

root@tower:/mnt/cache/.appdata/nextcloud# id nobody
uid=99(nobody) gid=100(users) groups=100(users),98(nobody)

 

You can see the uid and gid end up the same.  So I don't know what you did and whether you changed the user:group in the docker or not, but  we recursively chmod everything to abc:abc on restart anyway. 

So it won't be persistent if you did WITHIN the container change everything to nobody:user

 

root@tower:/mnt/cache/.appdata/nextcloud# touch test
root@tower:/mnt/cache/.appdata/nextcloud# docker exec -it nextcloud bash
root@ee0c2bb53f10:/$ cd /config
root@ee0c2bb53f10:/config$ chown nobody:users test
root@ee0c2bb53f10:/config$ ls -la
total 0
drwxrwxrwx 6 abc    abc    84 Nov 12 22:41 .
drwxr-xr-x 1 root   root  206 Nov 12 01:19 ..
drwxr-xr-x 2 abc    abc    48 Jul  6 11:55 keys
drw-r--r-- 3 abc    abc    18 Jul  6 11:55 log
drwxrwxr-x 3 abc    abc    77 Jul  6 11:55 nginx
-rw-rw-rw- 1 nobody users   0 Nov 12 22:41 test
drwxrwxr-x 3 abc    abc    51 Oct 12 16:02 www

 

Then restart the container:

 

root@tower:/mnt/cache/.appdata/nextcloud# docker exec -it nextcloud bash
root@ee0c2bb53f10:/$ cd /config
root@ee0c2bb53f10:/config$ ls -la
total 0
drwxrwxrwx 6 abc  abc   84 Nov 12 22:41 .
drwxr-xr-x 1 root root 206 Nov 12 01:19 ..
drwxr-xr-x 2 abc  abc   48 Jul  6 11:55 keys
drw-r--r-- 3 abc  abc   18 Jul  6 11:55 log
drwxrwxr-x 3 abc  abc   77 Jul  6 11:55 nginx
-rw-rw-rw- 1 abc  abc    0 Nov 12 22:41 test
drwxrwxr-x 3 abc  abc   51 Oct 12 16:02 www

 

I'm pretty knackered as I've been at work all day, but I think maybe your problem was because for whatever reason your client is trying to access the docker using the group nogroup, when it really should be users.  Problem is if you've changed this and "fixed" your issue, this won't be persistent across container restarts.  I have no idea IF that is the right conclusion, but I can't think of anything else right now...

[KingB]

Thank you for that answer :-)

 

I changed it to nogroup and synced the devices with the big files. After that I restarted the container the chmod did its job.

 

So, for now I am fine, since small files and changes in files getting synced without any problem.

 

If the problem occours again, I know how to temporary fix it and that should be enought for now.

[theiam79]

So I've followed the guide to set everything up, and Nextcloud works fine, until I go to set up Reverse Proxy. I can successfully connect to the login portal through server.com/nextcloud, but this page takes several minutes to load. Following that up, I've only been able to successfully login once out of dozens of attempts, usually resulting in a 504 Gateway Time-out. FWIW I've nuked and redone this a few times to get to this point.

[CHBMB]

So I've followed the guide to set everything up, and Nextcloud works fine, until I go to set up Reverse Proxy. I can successfully connect to the login portal through server.com/nextcloud, but this page takes several minutes to load. Following that up, I've only been able to successfully login once out of dozens of attempts, usually resulting in a 504 Gateway Time-out. FWIW I've nuked and redone this a few times to get to this point.

Can't help unless you post your config files.  Make sure you edit out any sensitive information like username or password.

[theiam79]

Here you go. Everything else is working normally, so I'm not sure what's up, but appreciate any help.

config.txt

default.txt

[CHBMB]

What about your config.php?

 

Sent from my C6903 using Tapatalk

 

 

[theiam79]

That should've been attached to the last post but here it is again.

config.txt

[CHBMB]

That should've been attached to the last post but here it is again.

 

Nothing jumps out other than it will fail if you try and connect over http as there's no redirect rule to https.  Can you confirm that you're trying to access it via https?

[theiam79]

I am using https. I don't think it's a resource issue, as Unraid only shows a peak load of like 15% and available RAM. Like I said I nuked it and started over and that didn't change anything. I've also cleared the browser cache and what not, as the only time I got it to login successfully was in an Incognito window, but even that failed multiple times.

[CHBMB]

I am using https. I don't think it's a resource issue, as Unraid only shows a peak load of like 15% and available RAM. Like I said I nuked it and started over and that didn't change anything. I've also cleared the browser cache and what not, as the only time I got it to login successfully was in an Incognito window, but even that failed multiple times.

 

I never suggested it was a resource issue...   

 

So looking at your config the only thing I have noticed is these lines.

 

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

 

Try #ing them out and restart Apache and see what happens...