--move troubleshooting

[ThePowerTool]

Code: Select all

[guest@[my system] ~]$ cat /etc/redhat-release 
Fedora release 36 (Thirty Six)
[guest@[my system] ~]$ rpm -qa | grep -i transmission
transmission-common-3.00-14.fc36.x86_64
transmission-cli-3.00-14.fc36.x86_64
transmission-gtk-3.00-14.fc36.x86_64
transmission-3.00-14.fc36.x86_64
[guest@[my system] ~]$ transmission-remote -V
transmission-remote 3.00 (bb6b5a062e)

I'm using the --move command:

Code: Select all

transmission-remove -t[#] --move /directory

The response is

Code: Select all

localhost:9091/transmission/rpc/ responded: "success"

but when I check the directory is present but without contents. Everything is still in the initial directory and the Location remains unchanged.

The fact that the Location remains unchanged seems to indicate that, somehow, the Transmission client understands the --move process failed but, as stated above, returned a "success."

I looked at permissions--I know just-enough about permissions to get myself into trouble.

I'm using NAS.

My one "test" was to manually attempt a CL mv which was successful.

The directory and contents permissions (source dir):

Code: Select all

[guest@[my system] ~]$ ls -l /home/guest/NAS/Transmission-INPROG/ | grep mytorrent
drwxrwxrwx+  2 1001 root          0 Jan 30 13:23 mytorrent
[guest@[my system] ~]$ ls -l /home/guest/NAS/Transmission-INPROG/mytorrent
-rwxrwxrwx+ 1 1001 root         63 Oct 15 11:52 mytorrentfile.txt
-rwxrwxrwx+ 1 1001 root 1109177123 Jan 29 19:37 mytorrentfile.dat

The directory and contents permissions (target dir):

Code: Select all

[guest@[my system] ~]$ ls -la /home/guest/NAS
total 28
drwxrwxrwx+    9  1001 root      0 Jan 30 01:18 .
drwx------.   31 guest guest 20480 Jan 30 14:57 ..
drwxrwxrwx+    3  1001 root      0 Jan 30 01:19 Backups
drwxrwxrwx+    4  1001 root      0 Jan 30 14:43 Transmission
drwxrwxrwx+  293  1001 root      0 Jan 30 13:23 Transmission-INPROG
[guest@[my system] ~]$ ls -la /home/guest/NAS/Transmission
total 0
drwxrwxrwx+ 4 1001 root 0 Jan 30 14:43  .
drwxrwxrwx+ 9 1001 root 0 Jan 30 01:18  ..
drwxr-xr-x+ 2 1001 root 0 Jan 30 14:43 'mytorrentdir'

I realize the move failure may not be Transmission but it seems the "success" message for the move command followed by the unchanged Location in the transmission client indicates a bug.

I would sincerely appreciate any pointers on how to troubleshoot this issue.

Thank you very much!

[ThePowerTool]

OK,

RTFM. I spent time going back through everything on mounting CIFS shares.

The fix:
1. Two files need the setuid (suid) bit to support user mount (without sudo):

Code: Select all

[root@client ~]# ls -l /sbin/ | grep cifs
-rwxr-xr-x. 1 root root      54176 Apr 30  2022 mount.cifs
[root@client ~]# ls -l /bin/ | grep mount$
-rwxr-xr-x. 1 root root      49240 Jun  1  2022 mount

[root@client ~]# chmod u+s /usr/sbin/mount.cifs
[root@client ~]# chmod u+s /usr/bin/mount

-rwsr-xr-x. 1 root root      54176 Apr 30  2022 mount.cifs
-rwsr-xr-x. 1 root root      49240 Jun  1  2022 mount

2. Updated /etc/fstab with the "user" option for applicable entries:

Code: Select all

//nassrvr/dir1 /home/guest/dir1 cifs vers=1.0,rw,auto,user,uid=1000,gid=1000 0 0
//nassrvr/dir2 /home/guest/dir2 cifs vers=1.0,rw,auto,user,uid=1000,gid=1000 0 0

Note: Connecting to an older NAS I must specify the option "vers=1.0" indicating the older version of smb to successfully connect. Yes, I'm looking forward to upgrading that old server.

3. Make sure affected entries are unmounted (as a remount is required)

4. After updating /etc/fstab:

Code: Select all

[guest@client ~]$ systemctl daemon-reload

After this you can reboot, issue the mount command or simply have the user perform the initial mount, manually.

Now I have user-access (rwxr-xr-x / 755) and everything works, as expected.

I don't know why I didn't catch this, initially, as it's all basic set-up.
______________________________________
Now:

The only item remaining is the potential bug where the transmission client doesn't kick an error on the permissions failure.

If someone can confirm this is an issue that should be bugged I'm happy to post the details for a bug report--I just don't want to risk wasting dev time without a 2nd opinion.