SSL/TLS error connecting to network share over FTPS

Yea it’s only an entry level NAS but still :unamused:

I assume without SSH access that you can’t install iperf3?

You would really know better than me but I think it’s not an option

Okay so adding only the readfactor at 5 in my cache settings has done the trick. Playback starts pretty quickly and there is no skipping, judder etc.

Some minor issues just that are left:

  1. skipping ahead or back more than like 10 seconds during playback often results in video freezing and then RAM maxing out. Only resolution is to press stop and wait about 10 minutes for life to return, or a hard reboot.

  2. idle time for users on the FTP server is maxed to 10 mins, so if a user does not start any video/music within 10 mins of boot up then the pi must be restarted in order for the FTP to become accessible again.

Again, minor issues but would be nice to get them resolved.

I should be able to test the remote connection in a few days time and will update again.

Thank you @bmillham and @Tom_Doyle for all your help with this.

Hi,

Is this on the pi, is memorysize are default?

Is this a new issue or did kodi ftps have the same issue? sounds like a server side issue.

Thanks Tom.

Yes, on the pi with default memorysize. Should I try tweaking it? It’s the Pi B+ fyi.

I think this was always an issue but has only become apparent now, and yes very much looking like this is just the server limitation which I will just have to live with, unless using autofs instead of fstab might help?

If you only set the readfactor and nothing else on a RPi then Kodi should not use any significant amount of RAM than it was without that change. You might want to use top to try to see where the RAM is being used. Unless you also set the buffermode then I don’t even think that setting should have been active with a system mount. I think we would need to see exactly what you put in your advancedsettings.xml file.

fstab is going to open the connection and assume the connection is good. If your NAS is going to drop on idle then autofs would be the most likely solution as it closes the connection on idle and reconnects on demand.

HI,

Ok worked autofs, hope this helps the idle issue. Overview of autofs can be found here:

for ftps:

/etc/auto.master:

/- /etc/auto.ftp.shares --timeout 60, --ghost

@richy The below autofs entry wasn’t working as it needed a space before the port (I’d only tested using 21 this morning) I’ve corrected this below now.

/etc/auto.ftp.shares:

/mnt/ftp -fstype=fuse,ssl,allow_other,no_verify_peer,no_verify_hostname,user=USER:PASWORD curlftpfs#192.168.1.13:3688

/mnt/ftp -fstype=fuse,ssl,allow_other,no_verify_peer,no_verify_hostname,user=USER:PASWORD curlftpfs#192.168.1.13 :3688

Try that and let us know how you get on.

As for the seeking issue, you try increasing the readfactor to 6 or 7; I wouldn’t go any higher though.

Thanks Tom.

Okay so I now have the RPi in a remote location and have been able to test it out.

I decided to stick with fstab for mounting the remote share as autofs seemed to be glitchy.

I’m able to log into SSH and FTP on the pi remotely, however the fstab is not able to successfully mount the remote share. I’ve made sure to check that the remote share address was changed in the fstab beforehand but it just won’t connect.

I’m using duckdns as a dynamic DNS provider. Details here and here.

I was thinking it must be something to do with the port, but I can easily login from a remote location to FTPS using Android apps using the same address+port, so really not sure what the issue is here.

Attempting to connect via command line looks like it succeeds (I think) but the when checking the mounted directory it is empty and so clearly didn’t work. Here is the log for that.

Appreciate any suggestions thanks.

Hi,

Please provide the fstab entry for the remote share and full kodi logs.

Thanks Tom.

fstab entry (credentials omitted)

curlftpfs#user:password@mydns.duckdns.org:3688 /mnt/ftp fuse ssl,no_verify_peer,no_verify_hostname,allow_other,x-systemd.automount,noauto 0 0

Kodi log
https://paste.kodi.tv/enopuvutah.kodi

thanks

If you are willing to let me experiment, could you setup another user/password and PM me the details? I’ll give this a try here to see if I can get it working if you will.

1 Like

Have messaged you with the details. thanks

I think I found what’s going on. I’m able to connect, but when I try to do an ls, I get:

ls: reading directory '.': Input/output error

Turning on the debug option, I noticed that after the initial connection, ftpfs was trying to use your internal IP, so while the control channel seems open, it’s unable to transfer data. I added skip_pasv_ip to the options, so my fstab looks like this now:

user:password@mydns.duckdns.org:3688 /mnt/ftptest fuse.curlftpfs ssl,no_verify_peer,no_verify_hostname,allow_other,skip_pasv_ip,x-systemd.automount,noauto 0 0

and now it works! Notice one other small change that I made, instead of using the older curlftpfs# syntax, I used the newer fuse.curlftpfs syntax. Not really needed, but looks cleaner.

3 Likes

Awesome, I can confirm it works! Will test further but for now it looks like I’m all set up! Thank you @bmillham and @Tom_Doyle for all your help with this :pray:

It might be worth condensing this thread into a guide similar to those on configuring fstab for samba and NFS shares.

I don’t suppose any of this would be possible on an unrooted android smartphone?

One final somewhat unrelated issue I noticed when setting the pi up in the new remote location is that in MyOSMC add-on in networking I only have a menu item for wired ethernet but nothing for wireless (WiFi), is this a known issue on 18.5?

1 Like

Are you using an older RPi with a USB wifi dongle? Support was dropped for some adapters and if you wish to know more about that there are several lengthy threads covering that topic.

1 Like

I was thinking of doing that. I’ll also get it working with autofs so I can update that topic.

How is the performance for you using ftpfs? When I tested between 2 systems at home, the performance was not real good. Probably fine for up to 1080p, but I think it would have problems with 4K UHD. I haven’t tried yet, but I believe that there is an option to only encrypt the control channel and not the data, so login information, etc. would be encrypted, but the actual file data would not be. This would probably give you a major speed boost. I’ll update this thread once I’ve tested and confirmed that.

I did some more local testing. I wanted to verify that the changes would also work on your NAS, but it looks like you removed the account you setup for me so I couldn’t. So give this new fstab entry a try and see how it works for you:

user:password@mydns.duckdns.org:3688 /mnt/ftptest fuse.curlftpfs ssl_control,ftp_method=singlecwd,no_verify_peer,no_verify_hostname,allow_other,skip_pasv_ip,gid=1000,uid=1000,x-systemd.automount,noauto 0 0

I made a few changes:
ssl_control will only encrypt control messages. With this option data transfer is not encryted, and is about 6 times faster in my local testing.
ftp_method=singlecwd should speed up things a little bit also.
gid and uid=1000 so that files will be shown as being owned by osmc/osmc

let me know if these options work for you.

1 Like

Testing 1080p playback worked okay today and seemed to hold up just fine with encryption. I think I will keep the encryption enabled as there is no real need to disable it for increased throughput in my particular circumstances as the RPi I have can’t handle 4K content anyway so no biggy. I suppose others may wish to use this option though.

I will test with the other parameters (ftp_method, gui and uid) in the next few days.

I have no easy/good way of getting detailed performance statistics on my FTP server, so I’ve enabled your test FTP account again and placed a decent bitrate 1080p file in the share if you want to test a little more. Just FYI my connection has 6.7 Mbit/s upload currently.

If it’s fast enough for you, then probably leave things as they are, but I would recommend that you add the gid/uid options.

You can test the speed from the Pi with this command:

dd if=/mnt/PATH/TO/FILE of=/dev/null bs=1024 count=10M status=progress

Since you turned on the account again, I was able to confirm that the options do work on your NAS. I can’t really do a speed test, as I have satellite internet. It would not be a real-world test.
I did notice that just doing a cd and ls is noticeably faster, probably it’s the ssl_control option speeding it up.

Go ahead and disable the account again, as I’ve confirmed what wanted to know. (You may want to leave it disabled if you can so you could turn it on again if we need to do more testing).

Thanks Brian!

Further testing today has shown that unfortunately the NAS cannot maintain a sufficient upload speed as playback freezes every 5 minutes or so for a short period then resumes playback again.

I will have to try again with the data encryption disabled (and additional tweaks) to see if I get any better results and update in a few days.

Edit:
Ran some speed tests locally on my Vero 4K+ just to compare speeds with and without encryption etc. Results are below:

Local Vero 4K+ over FTPS with encryption
1583751276 bytes (1.6 GB, 1.5 GiB) copied, 1238.62 s, 1.3 MB/s

Local Vero 4K+ over FTPS without encryption
1583751276 bytes (1.6 GB, 1.5 GiB) copied, 719.265 s, 2.2 MB/s

Clear improvement on the Vero here. Will be able to run the same test on the RPi with remote FTP over the next few days or so.

I still wonder why you not just establish an openvpn connection instead which would not only allow you to access the media but being able to manage the devices remotely.