29 minutes ago, Gekko said:

I installed the crontab using vanilla variables

You still have the modified values, probably reinstalled form previous apps (which keeps your settings) instead of reinstalling from apps.

 

 

Also check the logs of the cronjob container for pointers

 

For the php values the container probably only handles what's needed. Upload size etc typically would not need being changed, if you have issues with those it's likely at the reverse proxy level.

Edited August 4, 20241 yr by Kilrah

16 minutes ago, Kilrah said:

You still have the modified values, probably reinstalled form previous apps (which keeps your settings) instead of reinstalling from apps.

Thanks for pointing that out, i didn't expect there's a different behavior by doing that. Thanks! Regarding PHP, i'm sure, i can handle this involving the proxy, it was just an idea to place it with the extra parameters, but this is no crucial thing.

 

So, i reinstalled the nextcloud-cronjob container with the parameters being *REALLY* fully vanilla, the log seems to be ok, still no luck at the backend.

 

Did you wait 15 minutes after installing?

Does anyone know what needs editing in order to increase the file size limit to upload via WebDAV? I have no issues uploading large files to the iOS app or via PC however I am using the iOS app Photosync as it can upload all my images without removing any of the metadata and preserves quality, plus its very easy to upload and keep your folder and album structure, however when I try to upload videos of around 2GB I get “413 Request too large”

 

My Nextcloud dashboard has the correct numbers with a 200GB Upload limit but just want to know if there is something separate that needs editing for WebDAV uploads?

Might be the reverse proxy config. 

I have sorted me previous issues out with transferring via WebDAV, the only issue I have currently is getting transcoding working on the memories app. I have Intel GPU TOP installed and have added /dev/dri as an extra device, this works great for Transcoding on Plex but I presume there’s some extra setup needed on memories, I have tried to type the video command in the terminal but it says its not defined so I am a bit stuck, do I need to edit anything on the memories setup page?

Enable HW acceleration but NOT external transcoder (that would be if you have another container to do that)

 

So I have done that and restarted the container, but when I click a video I just get a black screen with the swirling logo as if the video is loading but nothing happens

And it shows HW accel being detected? What's in the logs?

My Nextcloud logs just say “Transcode failed - Transcoder returned 408”

Upgraded to version 30 from 29 and it went into maintenance mode. I had to use the tips below to manually get it out of maintenance:mode

 

 

I did the upgrade on my test setup and it went fine, although some apps (including Memories...) didn't support 30 yet. I see Memories got an update since so I'd expect it does now, haven't checked. As usual I won't update my main instance or point the latest tag of this image to 30 until 30.0.1 is out. 

Edited September 23, 20241 yr by Kilrah

I got an update info through the unraid/apps/action-center notifications.

There's no info about the version this update will end up. Can someone give me a hint how to find this out?

Backend says i'm on the latest version 29.0.7.

 

Thanks

The default tag is still 29, so it's still 29.0.7, just they republished the image maybe because of a minor patch. Full version is 29.0.7.1, they just don't mention the 4th level anywhere.

 

Anyway you should still specify the major version yourself e.g. kilrah/nextcloud-ffmpeg:29 in the Repository line so you control when you do major updates. But then you need to remember to actually do it.

Edited September 27, 20241 yr by Kilrah

Me again with some different issue:

since i have Nextcloud-FFMPEG installed, i get the message 'Your data directory is readable by other users. Please change the permissions to 0770 so that the directory cannot be listed by other users' every time i perform an update, sometimes when restarting the container. Now, this error occured 3 times during a day without the container or unraid even touched - so it endangers the reachability of the server.

 

To solve this, i usually get inside the docker via

sudo docker exec --user root -it Nextcloud-ffmpeg bash

 

and ls'sing the directory shows what's wrong:

 

so i use chown to fix that:

chown -R www-data:www-data ./data

 

And then everything works fine. But it bothers me that this happened 3 times this day and there is no warning or some action from the user's side indicating a possible change of that folder rights.

 

My question: can i prevent this from happening in any way? I'm no expert using unraid/docker so forgive me if this is trivial to solve.

 

Thanks alot for help!

Need more info about your setup. What's the nextcloud data folder stored on? what filesystem? The root of a share or another folder?

• /data is on the array (xfs/folder rights: sshd)
• /appdata is on the cache (nvme/btrfs/folder rights: sshd), the empty /data folder in there had folder rights for nobody, no idea why, never touched them
• opcache-recommended.ini is on the array (xfs/ folder rights: root)

--> I changed the folder rights in cache /appdata/data from nobody to sshd now to see if this works.

 

I deployed the Nextcloud-FFMPEG distribution on another machine from scratch with the same result as described above, the error is reproducable even on a very fresh installation.

Yeah, so i changed the folder rights from nobody to sshd and it happens again, without anybody barely interacting with Nextcloud:

 

 

It's really getting SUPER annoying, cause this seems to happen when the processors are under heavy load. And this could be anytime plugging off the cloud from working. This is far from reliable right now.

 

terra-diagnostics-20241029-0340.zip

Edited October 29, 20241 yr by Gekko

Is anything else accessing the data folder other than nextcloud? Being shared over the network? New Perms being run?

Nothing. Nextcloud is an operational isolated instance here, meaning there is no interacting with other tools/dockers.

 

And as i said, all of this is happening in parallel on a seperate machine running unraid and Nextcloud-ffmpeg/MariaDB/Redis/Cron: the whole setup there is just an standard operational Nextcloud instance with no sharings in data or permissions.

And the folder rights of /data are happening there as well - after every update, reboot and processor load.

 

I really can't believe there is no solution for this and nobody has had any issue with folder rights changing multiple times a day...when i have two installations doing exactly this.

Yup, never heard of that except in the case of the data being at the root of a share that's on a zfs drive. 

 

There has to be something that interacts with it and is set to use 99:100...

Edited October 30, 20241 yr by Kilrah

As far as i dove into the issue, i realized a bad config of the cache settings. I'm using redis to take care of cache and in my config there was still a line left naming ACU as cache method. Since i got rid of that line, the issue seems to be solved.

 

EDIT:

--------

No, the issue is not solved. Nextcloud-ffmpeg still keeps changing the ownership of the /data folder randomly, destroying the reachability of the cloud. As there is no support finding the reason for this, i truely can't recommend this Nextcloud distribution as ist is not reliable at all.

Edited November 7, 20241 yr by Gekko

Hi Gekko, definetly you have some issue that some service is changing ownership on your files.

I am using Kilrah Nexcloud instance for very long and did not had issue at all with it so nice job @Kilrah 

 

If you cannot pin point from where issue exist you can always change config in config.php adding:

'check_data_directory_permissions' => false,

that shall fix your issues.

 

I'm trying to migrate to this from the Linuxserver container.  I have a separate Mariadb container hosting the database.  I recreated the extra variables and paths, and I accessed the gui.  It is asking me to create an admin account so I do that, and specify a Mariadb database with the appropriate information, and I keep getting an error "Cannot create or write into the data directory /var/www/html/data".  That's defined as the /data path, has 777 permissions, etc. 

 

Any ideas on how to fix this, or otherwise migrate to an existing instance without recreating most everything?

I've done it back in the day so it's possible, but LSIO have their own standard paths so you have to move stuff around. I.e. recreating the lsio paths in this won't work, I'd recommend you make a clean, separate install of this one in another folder so you can look at where stuff is and move the old LSIO appdata accordingly.