Cannot Delete Directory Created by Transmission

[PiP]

Hello,

I am trying to solve a problem that has been discussed elsewhere in this forum, but not quite working for me. My transmission setup includes a mount point:
Source:
/mnt/NAS/media/_torrents

Destination:
/mnt/NAS/jail/software/usr/pbi/transmission-amd64/etc/transmission/home/Downloads

Also I access /mnt/NAS/media via windows share (i.e. //NAS/media). I can access files (rwx) in this directory via this windows share.

My original transmission setup successfully downloaded files, which were also visible via the mount point /mnt/NAS/media/_torrents. However I was not able to delete files or directories via windows share (I did so using via shell session using the freenas web gui).

Having followed the instructions in this thread: (http://forums.freenas.org/showthread.php?8175-Transmission-folder-permissions) vis changing "umask": 0, I am now able to delete files created via transmission, but not directories (or rename them).

ls -l on the directory created reports:
drwxrwxrwx 2 40002 40002 2 Oct 4 21:22 Directory

Again, this can be deleted via a shell session through the web gui, but not via a windows "session".

I think it is a permission issue, but I'm not familiar enough with unix like systems to really understand where to start looking, or what I am looking for, let alone concepts like jails etc..

Any help would be appreciated.

regards

PiP

 

[cimimonsti]

It looks like user and group, 40002 and 40002, are the owners of the directory. The third 'rwx' represents read, write, execute permissions for any user. However, I think these permissions are set within the plugin. They don't apply to users from outside the plugin, which are FreeNAS users.

In your particular case. Try creating a group in FreeNAS WebGUI. Name it 40002. Then under Auxiliary groups, add your username to the group you've just created. You'll be able to modify directories since you belong to the same group set forth by Transmission, which is 40002. This should work in theory.

Let me know if it works out, and report back.

/cim

 

[mPich]

It looks like user and group, 40002 and 40002, are the owners of the directory. The third 'rwx' represents read, write, execute permissions for any user. However, I think these permissions are set within the plugin. They don't apply to users from outside the plugin, which are FreeNAS users.

In your particular case. Try creating a group in FreeNAS WebGUI. Name it 40002. Then under Auxiliary groups, add your username to the group you've just created. You'll be able to modify directories since you belong to the same group set forth by Transmission, which is 40002. This should work in theory.

Let me know if it works out, and report back.

/cim

im have same problem
creating a group in FreeNAS WebGUI does not work

 

[PiP]

Cim,

Things have gone bad to worse, and am now finding that Transmission not working at all. something has gone awry - not sure what or how, but can only think to uninstall and start again.

Will do that this weekend time permitting, and if I come across the same issue will try your solution to see if it corrects the issue.

Thanks for your input regardless.

PiP

 

[cimimonsti]

PiP,

If you get a chance. Describe what bad to worse is. Plugins are now isolated in 8.xx versions. You should haven't to reinstall FreeNAS, unless something was done in the shell, or factory settings were implemented. Please elaborate as someone can assist you, and it may help others. We look forward to hearing you out.

mPich,

creating a group in FreeNAS WebGUI does not work

Can you tell us what you mean exactly? What doesn't work? If you're talking about creating groups or even users, and it not letting you. Try rebooting your machine. A common bug within the GUI is that the permissions section will still require you to checkboxes, even after doing so. Clearing your cache isn't enough, try a reboot.

If it's something else, please elaborate.

/cim

 

[ProtoSD]

Destination:
/mnt/NAS/jail/software/usr/pbi/transmission-amd64/etc/transmission/home/Downloads

I don't know if this will help or not, but don't use the first part of the path highlighted above. The destination path should be the path as it is from INSIDE the jail, so "/usr/pbi/transmission-amd64/blah-blah-blah".

 

[PiP]

All, I gave this another look over before taking any drastic action and - for what ever reason- it now appears to be working as intended. I am thinking that a reboot and or stopping the transmission plugin might have made the difference.

Thanks for the help regardless. Will attempt reboots and restarts before I post again...

 

[Sconsalter]

For me the solution was the simpliest possible.

I gave permission to plugin jail folder for Transmission, as below:

Now I can delete or write at my download folder designed for Transmission.

 

[Jailer]

Do you realize you just responded to a 2 1/2 year old thread?

 

[Sconsalter]

Do you realize you just responded to a 2 1/2 year old thread?

Yes, but this thread had no closure at that time. It will be helpful for someone else that would search the solution from now on.

 

[Joshua Parker Ruehlig]

For me the solution was the simpliest possible.

I gave permission to plugin jail folder for Transmission, as below:
View attachment 8010

Now I can delete or write at my download folder designed for Transmission.

by changing the permissions for your jail dataset your jail will no longer work. I bet if you try restarting the syncthing service it won't work properly. this isn't the proper to do ever.

 

[SweetAndLow]

For me the solution was the simpliest possible.

I gave permission to plugin jail folder for Transmission, as below:
View attachment 8010

Now I can delete or write at my download folder designed for Transmission.

Joshua is correct, don't do this. You shouldn't modify the permissions on your jail dataset or the permissions of the jails. Only modify the permissions of your data and shared storage.