Transmission

[gerry1234]

For new Package Requests, see the guidelines

Setup

_Package Name:_Transmission
_Package Version:_2.92-12

_NAS Model:_DS416Play
NAS Architecture: Intel x86 CPU 64-bit
_DSM version:_6.0.2-8451

Expected behaviornot downloading

Tell us what should happenUmm, download?

Actual behaviorStops after 5 seconds

Tell us what happens insteadas above

Steps to reproduce

1.
2.
3.

Package log

Check Package Center or /usr/local/{package}/var/

Insert the package log here

Other logs

E.g. /var/log/messages or /var/log/synopkg.log

Insert log here
Transmission stops downloading after 5 seconds. Ports are open canyouseeme.org says ports are open. Transmission says port is open

[gerry1234]

Transmission stops downloading after 5 seconds. Ports are open canyouseeme.org says ports are open. Transmission says port is open

[MxMatrix]

Transmission does install but after that a message appears: Failed to run package service.

(DSM 6.0.2-8451 / DS412+)

[gerry1234]

As good as dead then!!

On August 30, 2016 2:54:20 AM MxMatrix [email protected] wrote:

Transmission does install but after that a message appears: Failed to run
package service.

(DSM 6.0.2-8451 / DS412+)

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#2434 (comment)

[dontevenblink]

DSM 6.0.2-8451

DS1815+

Transmission 2.92-12

I got the same "failed to run package service" after installation but I successfully started it manually after a DSM restart. I was able to connect to the administration page, load a torrent file and start seeding existing data. I have not tried a download yet.

I am having a port forwarding issue - but I may be doing it wrong. I have successfully port forwarded in transmission on other platforms many times. I went to my router and forwarded TCP/UDP traffic on port 54074 to the local IP of my DS1815+. I used an internet based port check and my port registers as 'OPEN' from the outside. However, on the transmission mgmt page options where you select the port it still shows up as closed. My synology is connected to the local network via an 'adaptive load balancing bond'. I'm used to the 'open' indicator in transmission telling me I've done this right, but the external check shows it open.

Any thoughts? I'll test downloads ASAP and report back.

[MxMatrix]

Nope ... restart did not change anything. Started it manually, same error message.

[raxpyraxp]

I have this issue too. I've done little investigation. Basically, what I understand is that "su" command is not working properly with 'transmission' account.

I have DS212j with DSM 6.0.2-8451.

Right after install I have this:

root@DiskStation:/# cat /etc/group | grep transmission
sc-download:x:65537:transmission

root@DiskStation:/# cat /etc/passwd | grep transmission
transmission:x:100:100:Transmission User:/usr/local/transmission/var:/bin/sh

root@DiskStation:/# su transmission
su: Permission denied

root@DiskStation:/# su transmission -c "echo hello"
su: Permission denied

root@DiskStation:/# su transmission -c "ls -la"
su: Permission denied

Of course, transmission command by itself is not working too:

root@DiskStation:/# su transmission -c "PATH=/usr/local/transmission/bin:/usr/local/python/bin:${PATH} /usr/local/transmission/bin/transmission-daemon -g /usr/local/transmission/var/ -x /usr/local/transmission/var/transmission.pid"
su: Permission denied

/var/log/messages right after install and run:

2016-09-02T20:02:31+04:00 DiskStation transmission-daemon[8232]: Couldn't save temporary file "/usr/local/transmission/var//settings.json.tmp.0XbLJP": No such file or directory (variant.c:1280)
2016-09-02T20:02:31+04:00 DiskStation transmission-daemon[8232]: Couldn't save temporary file "/usr/local/transmission/var//dht.dat.tmp.TEjtEd": No such file or directory (variant.c:1280)
2016-09-02T20:03:40+04:00 DiskStation synoscgi_SYNO.Core.Package.Installation_1_install[13020]: resource_api.cpp:163 Acquire service-cfg for transmission when 0x0001 (done)
2016-09-02T20:03:46+04:00 DiskStation kernel: [ 9273.160000] init: pkgctl-transmission pre-start process (13314) terminated with status 1
2016-09-02T20:03:46+04:00 DiskStation synoscgi_SYNO.Core.Package.Control_1_start[13020]: servicecfg_internal_lib.c:187 Failed to start job [pkgctl-transmission][0xD900 privilege.cpp:60]
2016-09-02T20:03:48+04:00 DiskStation synoscgi_SYNO.Core.Package.Control_1_start[13020]: service_initjob_action.c:27 InitJobStart failed, [0xD900 privilege.cpp:60]
2016-09-02T20:03:48+04:00 DiskStation synoscgi_SYNO.Core.Package.Control_1_start[13020]: pkgstartstop.cpp:262 Failed to start pkgctl-transmission (err=-1) [0xD900 privilege.cpp:60]

BUT

root@DiskStation:/# sudo -u transmission -i
transmission@DiskStation:~$ whoami
transmission
transmission@DiskStation:~$ id
uid=100(transmission) gid=100(users) groups=100(users),65537(sc-download)

root@DiskStation:/# sudo -u transmission PATH=/usr/local/transmission/bin:/usr/local/python/bin:${PATH} /usr/local/transmission/bin/transmission-daemon -g /usr/local/transmission/var/ -x /usr/local/transmission/var/transmission.pid
root@DiskStation:/# ps -ef | grep transmission
transmi+  9233     1  0 21:03 ?        00:00:00 /usr/local/transmission/bin/transmission-daemon -g /usr/local/transmission/var/ -x /usr/local/transmission/var/transmission.pid
root      9477 17251  0 21:03 pts/3    00:00:00 grep --color=auto transmission

Obviously, start-stop-daemon script works like that:

start_daemon ()
{
    #su - ${USER} -c "PATH=${PATH} ${TRANSMISSION} -g ${INSTALL_DIR}/var/ -x ${PID_FILE}"
    sudo -u ${USER} PATH=${PATH} ${TRANSMISSION} -g ${INSTALL_DIR}/var/ -x ${PID_FILE} 
}

So, sudo works, su not, but if I modify /sbin/nologin to /bin/sh in /etc/passwd for one of user, which was created by web interface - su works for them.

[MxMatrix]

Sounds like Synology changed the way su works on their devices, more safe but restricting the use of 3rf party packages. Should this be re mediated in the way the transmission package is installed?

[rux616]

DSM 6.0.2-8451 Update 1
DS1512+

After doing a bunch of poking around, I found out the transmission user created during the install of the package doesn't have an entry in the /etc/shadow file.

I added the line transmission:*:17049:0:99999:7::: to the end of the file and Transmission started right up.

It seems that whatever process is currently being used to create the transmission user doesn't finish the job, leaving things in a broken state.

[KaraokeStu]

Hi @rux616 this is a known issue with the way the packages created users as part of 5.x packages, however Synology changed the method to create them in 6.x

We're working on a few proofs of concept at the moment, and will keep you posted

[IceC00l]

Hi all, just wanted to add that if you edit the start-up-script under /var/packages/transmission/scripts and insert as USER "root" instead of "transmission" the service will start correctly (just a temp workaround). I confirm that "su" fails to work as with DSM 6 the behavior changed for increased security (they also removed direct root login). "sudo su" works fine with your admin password but just su will fail, even if you had set a root password via cli.
The package installs fine (just don't run it) if you set the permissions of the folders correctly before installing it (user group) and specify the correct ones. However as mentioned su fails to run (permission denied) after the DSM 6+ update (I have 6.0.2 Update 1 on a DS112j) unless you switch the user in the script to root.

[gerry1234]

"just a temp workaround.". <<< Really??

On October 6, 2016 6:25:50 PM IceC00l [email protected] wrote:

Hi all, just wanted to add that if you edit the start-up-script under
/var/packages/transmission/scripts and insert as USER "root" instead of
"transmission" the service will start correctly (just a temp workaround). I
confirm that "su" fails to work as with DSM 6 the behavior changed for
increased security (they also removed direct root login). "sudo su" works
fine with your admin password but just su will fail, even if you had set a
root password via cli.
The package installs fine (just don't run it) if you set the permissions of
the folders correctly before installing it (user group) and specify the
correct ones. However as mentioned su fails to run (permission denied)
after the DSM 6+ update (I have 6.0.2 Update 1 on a DS112j) unless you
switch the user in the script to root.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#2434 (comment)

[burgerga]

@worm202 You're completely right, and the developers are aware of this issue, only it's taking a little longer: #2216

In the meantime I replacede all su - ${USER} with sudo -u ${USER} and added the following line to my /etc/sudoers:

%administrators ALL=(transmission) NOPASSWD: ALL

This let's all administrators execute commands as transmission without the need to enter a password, still a dirty hack, but better than just executing it as root ;)

[burgerga]

@mytelegrambot could be... Can you try to add some logging statements (eg to /volume1/Public/) to see if it even tries to use the script?

[KaraokeStu]

Have you tried seeing the owner of the script to the transmission user?

[KaraokeStu]

I meant setting!

[juanjoGL]

Are you going to publish more about this issue? Has it been closed?

[burgerga]

@juanjoGL No a duplicate issue has been closed, progress on this issue is most likely dependent on #2216 which might take a while

[KeizerSauze]

Any solution yet ? Thanks !

[juanjoGL]

Any news yet?

[vgabor99]

Hello,
I am trying to overcome this, until we get a final solution.
I set folder ownerships manually (to the transmission user). I set up a boot-time script to set the login shell for the transmission user. This works fine, I can start the service manually.
BUT, it does not start automatically after reboot.
Any ideas what is needed to trigger automatic start on boot?
Thank you

(PS. I am not willing to add transmission user admin rights.)

[juanjoGL]

Hi,

Just to give a clue on the issue.. I have a DS214se and a DS212j. Recently I bought 2 new HDs to replace the ones installed in my DS214se and installed the DS214se from 0. I tried to install Transmission with no results (the problem mentioned and treated in this thread). I installed the old HDs of my DS214se in the DS212j and I got all the installed configuration and soft and data in the DS214se in the DS212j including Transmission that was previouly running in the DS214se before installing the new HDs. In a first view it seems a 0 cents clue but I have to mention that when stating the DS212j with the old HDs I had toinstall the latest versión of DSM.

Regards

[newkind]

Do we have any solution for this issue?

[m4tt075]

DSM6-compatible packages can be made available for testing purposes. If you are interested, please share your NAS model / architecture.

[themfinger]

Changing the startup script solved the problem, but I don't think we are supposed to run Transmission as root...
Thanks @IceC00l

[MxMatrix]

I have Transmission running since a few months now, after DSM 6.1 update 4 (I guess) installed it again. It does run as root ofc. Not the safest way perhaps but at least it runs.

[Safihre]

Test packages for DSM6.1 and various architectures are available here #3138. They also include a new way of handling permissions.
We hope to publish the packages to the official repo soon and appreciate all testing and reports on the functioning of these packages.

[isignupovertor]

For those coming to this issue after an upgrade from 5.x to 6.x. I fixed all my issues by doing a re-install of my packages. New install of packages works flawlessly (as of this date).

To do this, you basically take a backup of your packages, uninstall, reinstall, move data backup, fix up permissions.

• ssh into your synology box
• (ssh) cd /volume1/@appstore
• (ssh) sudo mv transmission transmission_backup
• Uninstall transmission via web interface
• Install transmission via web interfrace
• Confirm that it runs, and then Stop it.
• (ssh) sudo mv transmission transmission_dist
• (ssh) sudo mv transmission_backup transmission
• Check the permissions between the two folders, in my instance the users were different, scv-transmission vs sc-transmission
• make the transmission folder the same as the transmission_dist folder
• (In my instance it was) sudo chown -R sc-transmission:transmission transmission
• Start Transmission via the web interface

Hey presto you dont have any data missing.
Repeat the process for any other services you have with the same issues.