Downloading stopped at some errors, doesn't restart anymore about tubesync HOT 9 CLOSED

I just updated the two channels and changed the interval from 6 hours to 24 hours. And it seems that this triggered the tasks to start working again. I was probably just too impatient.

from tubesync.

Any chown or chmod issues would imply your download directory does not have its permissions set correctly (e.g. wrong owner or permissions). Make sure you're setting the PUID and GUID environment variables for the container properly to ones that can write to the download directory created outside of the container. Additionally, v0.8 has issues crawling large channels. This was fixed and is currently in :latest so you might want to try that image for now until the future v0.9 is released.

from tubesync.

I'll close this issue for now but comment again if you have not solved your errors.

from tubesync.

Regarding the chown problem.

My two directories are NFS mounted directories on the Ubuntu server. Access is read/write and all users are mapped to admin. Therefore the chown command fails (I did set the PUID and GUID to the right user (1000), and I can't seem to see any problems other than the log messages.

The server doesn't have enough disk space to host those downloads locally, although I could potentially move the config directory. I still prefer that to be that all on the NAS.

from tubesync.

Aside from permissions issues, TubeSync stores most of its data in an SQLite database in the config directory. It's usually not advisable to store SQLite databases on an NFS share, so if you can I would suggest putting the config volume on local storage. The videos / downloads can be on NFS without issue (assuming you set the permissions correctly!).

from tubesync.

Also having issues trying to restart the container while using an NFS share for the downloads directory. I think I have permissions set correctly but this is my first time mounting an NFS share. Only using NFS for the downloads, config is local. If anyone has suggestions or a guide for how I can debug I'd greatly appreciate it.

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 10-tubesync: executing... 
[cont-init.d] 10-tubesync: exited 267.
[cont-init.d] done.
[services.d] starting services
[services.d] done.

from tubesync.

@suth that log you pasted doesn't show anything out of the ordinary, that's just the normal start-up log of the container. Note you can drop a shell into the container to check permissions of you want (something like docker exec -ti tubesync bash) and check the /downloads directory is writable by the appropriate user (app if you've not changed anything).

from tubesync.

@meeb sorry, forgot to mention that was the output after making some progress, I was originally getting similar messages to @MatthK along the lines of chown: changing ownership of '/downloads/video': Operation not permitted but now I noticed the 10-tubesync: exited 267. and thought that may be something out of the ordinary.

I just decided to start a separate container without the NFS share and it seems like I'm getting the same result, so it seems likely I've solved my permissions issue and moved on to something else.

Edit: Rebooting my host machine seems to have solved my remaining issue!

from tubesync.

The "exited" line is just an initial start-up script completing successfully. It runs on container start-up to attempt to fix permissions and run any required database migrations:

https://github.com/meeb/tubesync/blob/main/config/root/etc/cont-init.d/10-tubesync

Glad you solved it with a reboot, NFS can be difficult.

from tubesync.