Deluge/smb/permissions

[tstuart]

Trying to setup deluge to download on one machine to an SMB share hosted on another. I know this is a permissions issue, but I am always getting the SMB permissions messed up and really need some guidance.

I have hostA with deluge and my actual storage on hostB - Both hosts are ubuntu (20.04) and VM's on the same ESXi
I have fstab in hostA mounting a share from hostB and point my clients to download there.
I ALWAYS have trouble getting permissions right when going between 2 ubuntu machines.
What do so the users/groups on HostA will be able to have RW a share on HostB.
On each host I have the same user (test) and on HostB the test user is also an SMB account.

From windows I can connect to the share and have the necessary RW access. But even with the share being mounted by fstab with the same user accont I used in Windows it's not allowing Deluge to RW. I'm assuming this is because of the account being used to start deluge.
From what I can tell though deluge is running as the user on HostA that I'm logging into the system with (test) and that user can RW the shared folder from the Cli..

[shamael]

Hi,

First a question: As both VMs are on the ESXi server why don't you download directly on hostA? Considering you may be on private trackers securing the torrent server availability may be a concern. Example: restarting hostB will lead to a recheck needed on all torrent on hostA. This will be slower with a network share vs local PVSCSI drive. Separated LVM VG group is a nie to have to scale it better for the futur (keep OS/torrent VG split).
Once downloaded on hostA you can perfectly read them through a samba share (Kodi, Windows, etc) without hurting the seeding.

Second your issue:
- what's your fstab entry
- the user in the fstab is the same than the one running Deluge on hostA?
- what if you create on the share a folder with full access to everyone and use it as target for Deluge?

I guess fstab user and Deluge user are different so Deluge cannot write on the share's root. But maybe it will with a subfolder accessible to everyone (or the Deluge user of hostA to secure it a bit).

[tstuart]

To first question:
my plex server is hostB and from back when I had separate physical boxes I always had the media on the same box as the plex server so I wouldn't have to worry about network transfers causing issues with playout. Inside the VMs this wouldn't matter as much(if at all really) but I just haven't got there yet. It does hurt the seeding when hostb reboots. But my preference is to hurt seeding when rebooting hostb rather than hurt playout when rebooting hostA.
Second question:
fstab: //192.168.1.42/storage /mnt/storage cifs user,username=tstuart,vers=3.0,password=sanitized 0 0

The user running deluge is tstuart
- /etc/systemd/system/deluged@.service has User=%i
- I then log into HostA with the tstuart account. I can sudo mkdir inside the wanted share. But deluge simply cannot do anything in there

I've been trying to create a folder that gives everyone access, as that would give me the work around I need and inside the network I'm not concerned with security. But even that I'm not seeming to get to work. I don't know why I cannot figure out these permissions between 2 linux machines - it can't be that hard but I must be missing something.

[tstuart]

On hostB the folder being shared out has permissions:
drwxrwxrwx+ 11 nobody nogroup

But on HostA the mounted share shows:
drwxr-xr-x 3 root root

I've tried sudo chmod -R u=rwx,g=rwx,o=rwx on both HostB and A but HostA never seems to change what it's showing as the permissions on the share.

[tstuart]

I think I get it now.
In fstab entry username/password are accounts on the remote machine, just used to authenticate.
the UID/GID are the local account that is mapping the share and therefore the account that will have access.
So when I was using root/root there was no way for lower accounts to properly access.
Only reason my tests were working is I used sudo and wasn't actually testing properly at all

[shamael]

Great you sort it out