Running Python Program via sshfs-mounted Share

Question

I have a share (on Machine-A) mounted via sshfs on Machine-B. From Machine-C, I have this share mounted also via sshfs (double sshfs) like so:

On Machine-C: /mnt/Machine-B/target_share

On Machine-B: /mnt/Machine-A/target_share

On Machine-A: /media/target_share

Now I have a Python program that runs fine in all places tested (including Machine-C on its local file system) except from Machine-C on the drive that lives on Machine-A, but is mounted on Machine-B.

The reason I am running the Python program from Machine-C is that it has the resources necessary to run it. I have run it on Machine-A and Machine-B and it has maxed the memory out on each, thereby failing each time. I have tried to mount the target_share on Machine-B with this type of command as well:

sudo mount -t cifs -o username=<username>,password=<password> //Machine-A/target_share /mnt/target_share

But this doesn't seem to work each way I have tried it, i.e., with different credentials, with and without credentials, etc.

To make matters worse, one caveat is that I can only SSH into Machine-B from Machine-C. I cannot directly access Machine-A from Machine-C, which, if I could, would probably make all this work just fine.

The Python program runs on Machine-C but the logic in the middle that I need to work doesn't run and gives no errors. It basically starts, and then ends a few seconds later.

I am relatively new to Python. Also, not sure if this post would be better on another board. If so, let me know or move as necessary.

I can post the Python code as well if I need to.

My apologies for the complicated post. I didn't know how else to explain it.

Thanks in advance.

Answer 1

I found that there may be a bug in sshfs, such that if a user on a Linux system has the same user ID as another, i.e., 1002, but different usernames, this causes problems.

The way I worked around this was to actually avoid sshfs for this case all together and mount the drives directly to a local system. I wanted to avoid this because I couldn't do this from a remote location, but it gets the job done.