CIFS Directory problem solved but maybe by brute force
Posted: Fri Dec 29, 2017 3:54 pm
I'm running Deluge 1.3.15 on Ubuntu and I had a directory permissions problem for weeks that I couldn't troubleshoot until now and the workaround might be a hack but I thought it might he helpful for others.
Upon boot I automount a CIFS share on my Synology NAS array. The authentication uses an AD domain controller running as a VM. I also attach to a VPN. When the Deluge daemon starts it checks to see if both of those things have completed successfully. I configured deluge to download the temporary and final files to the CIFS directory ~/lz. When this happens Deluge would create files and directories that it could not write to after they were created. If I did a sudo chmod to the contents it would work. I tried to solve this a few ways. I chown'd the directory to deluge (user that runs the daemon), I added deluge to the sudo group, added it to the root group, tried using the umask parameter. Nothing worked. Finally when I looked that the permissions on the files that were created by deluge I noticed that when deluge created a file it was not owned by any user I was aware of (my username, deluge, root etc) but by a number string for both user and group. I verified that it was the same string each time uid:2753561681 and gid:2753561089. This is consistent across daemon start/stop as well as reboot. Can't find a reference to this uid/gid anywhere so I just did a $ sudo chown 2753561681:2753561089 ~/lz and all work as expected now.
Now I have to go back and clean up my user/group memberships but it's working. Has anyone seem something similar? Not sure if this is a "deluge thing" or a "samba thing"
Cheers
Upon boot I automount a CIFS share on my Synology NAS array. The authentication uses an AD domain controller running as a VM. I also attach to a VPN. When the Deluge daemon starts it checks to see if both of those things have completed successfully. I configured deluge to download the temporary and final files to the CIFS directory ~/lz. When this happens Deluge would create files and directories that it could not write to after they were created. If I did a sudo chmod to the contents it would work. I tried to solve this a few ways. I chown'd the directory to deluge (user that runs the daemon), I added deluge to the sudo group, added it to the root group, tried using the umask parameter. Nothing worked. Finally when I looked that the permissions on the files that were created by deluge I noticed that when deluge created a file it was not owned by any user I was aware of (my username, deluge, root etc) but by a number string for both user and group. I verified that it was the same string each time uid:2753561681 and gid:2753561089. This is consistent across daemon start/stop as well as reboot. Can't find a reference to this uid/gid anywhere so I just did a $ sudo chown 2753561681:2753561089 ~/lz and all work as expected now.
Now I have to go back and clean up my user/group memberships but it's working. Has anyone seem something similar? Not sure if this is a "deluge thing" or a "samba thing"
Cheers