Solved curlftpfs ( vsftpd ) - Cant create new files but folders

I'm setting up a vsftp server and run in the following issue.

On the client machine I run:
curlftps ftpuser:pass@vsftpserver localFtpDir
This mounts my ftp server directories as I would expect.

Now, switching to my mounted folder "localFtpDir" and running mkdir newFolder inside works.
But, touch newFile does not.

If I connect to the vsftp server via ftp vsftpserver and login as ftpuser I can upload files though.
 
I'm setting up a vsftp server and run in the following issue.

On the client machine I run:
curlftps ftpuser:pass@vsftpserver localFtpDir
This mounts my ftp server directories as I would expect.

Now, switching to my mounted folder "localFtpDir" and running mkdir newFolder inside works.
But, touch newFile does not.

If I connect to the vsftp server via ftp vsftpserver and login as ftpuser I can upload files though.

Which version of CurlFtpFS are you using? I had a similar issue once I tried CurlFtpFS v0.92 on a macOS client and on a FreeBSD client. Most operations worked except file uploading. I had a close look into the code and compared it also with the original version 0.91 (which means 100 % by the original author Robson Braga Araujo), and the main difference is a thread-based file uploading system newly implemented by a second author.

Basically, this is a simple producer-consumer problem, which was implemented in the present case with the help of semaphores. I found that 4 semaphores were used instead of the usual 2 semaphores for thread coordination, and without further analysis we may have serious doubts as to whether such a system with independent 4 semaphores would ever run smoothly, i.e. without race conditions and deadlocks On Mac OS X and FreeBSD it did not, on Linux the semaphores may be smarter, who knows? Anyway, I did not see any advantaged of this new file upload method, even if it would have worked, so I did not even try to debug this threaded upload code, but simply just used Robson's original buffered upload system, which works perfectly. Just another case of a second cook spoiled the soup.

In order to make a long story short, use CurlFtpFS v0.91, this is the original and perfect version, and it still just works for me on macOS - on FreeBSD, I did not need it for several years now, and I cannot tell for sure whether it still works out of the box - perhaps it needs some fixes for new curl versions. Anyway, you can find v0.91 here: https://storage.googleapis.com/goog...e.google.com/curlftpfs/curlftpfs-0.9.1.tar.gz

In case you are using macOS as a client, you may be interested in the changes which I made for the Mac:
(German) https://obsigna.com/articles/1414801516.html
(English by the Bing Translator): https://www.microsofttranslator.com...=https://obsigna.com/articles/1414801516.html


PS: I just checked out the original version 0.9.1 of CurlFtpFS on a FreeBSD 12.0-RELEASE-p1 amd64 system, and unfortunately it does not work anymore. Then I tested the version which I modified for working with Mac OS X, and this one is fully operational also on the said FreeBSD machine (as well as on the latest macOS):

# fetch https://obsigna.com/articles/downloads/ftpfs-0.9.3.tar.bz2
# tar -oxjf ftpfs-0.9.3.tar.bz2
# cd ftpfs-0.9.3
# make install clean
# kldload fuse.ko

$ ftps ftpuser:pass@vsftpserver localFtpDir
$ touch localFtpDir/test
$ rm localFtpDir/test
 
  • Thanks
Reactions: mro
@T-Daemon: Thanks. Seems there is no "-o ftpfs_debug" option ?

I did run this for now:
curlftpfs -f -v -d ftp://172.16.1.2 ftpstuff

Which gives:
Code:
➜  ~ curlftpfs -f -v -d ftp://172.16.1.2 ftpstuff
*   Trying 172.16.1.2...
* TCP_NODELAY set
* Connected to 172.16.1.2 (172.16.1.2) port 21 (#0)
< 220 (vsFTPd 3.0.3)
> USER virtual
< 331 Please specify the password.
> PASS xxxxxxx
< 230 Login successful.
> PWD
< 257 "/" is the current directory
* Entry path is '/'
* ftp_perform ends with SECONDARY: 0
* Remembering we are in dir ""
* Connection #0 to host 172.16.1.2 left intact
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 19618
INIT: 7.8
flags=0x00000000
max_readahead=0x00010000
   INIT: 7.19
   flags=0x00000010
   max_readahead=0x00010000
   max_write=0x00020000
   max_background=0
   congestion_threshold=0
   unique: 1, success, outsize: 40

Code:
➜  ~ cd ftpstuff                                
➜  ftpstuff

# -------------------------
# This leads to this output
# -------------------------
ftpfs: operation ftpfs_getattr failed because No such file or directory
   unique: 8, error: -2 (No such file or directory), outsize: 16
unique: 9, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 3978
getattr /
   unique: 9, success, outsize: 112
unique: 10, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 3978
LOOKUP /.git
getattr /.git
   unique: 10, error: -2 (No such file or directory), outsize: 16
unique: 11, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 3978
LOOKUP /.git
getattr /.git
   unique: 11, error: -2 (No such file or directory), outsize: 16
unique: 12, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 3978
LOOKUP /HEAD
getattr /HEAD
   unique: 12, error: -2 (No such file or directory), outsize: 16
unique: 13, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 4741
getattr /
   unique: 13, success, outsize: 112
unique: 14, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 4741
LOOKUP /.git
getattr /.git
   unique: 14, error: -2 (No such file or directory), outsize: 16
unique: 15, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 4741
LOOKUP /.git
getattr /.git
   unique: 15, error: -2 (No such file or directory), outsize: 16
unique: 16, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 4741
LOOKUP /HEAD
getattr /HEAD
   unique: 16, error: -2 (No such file or directory), outsize: 16

I also tested to create a file, which did not work:
Code:
touch: hello.kk: Operation not supported

The debug output is similar:
Code:
ftpfs: operation ftpfs_getattr failed because No such file or directory
   unique: 735, error: -2 (No such file or directory), outsize: 16

Interesting though. I can edit and save files which are already in my mounted directory.
 
  • Like
Reactions: mro
I was hoping for some explicatory error messages. Not sure what more to suggest for troubleshooting. You could open a bug report at https://github.com/curl/curl/issues.
Seems there is no "-o ftpfs_debug" option ?
How so? Is the option not accepted? According to curlftpfs(1) and curlftpfs -h ftpfs_debug is a valid FTP option. Also a debug level can be appended, like:
Code:
curlftpfs -f -v -d -o ftpfs_debug=3 <ftpsite> <mountpoint>
To be fair, I have no possibility to verify the option, no ftp server to try on.
 
Do the following:
Code:
$ sudo pkg delete fusefs-curlftpfs
$ cd
$ fetch https://sourceforge.net/projects/curlftpfs/files/curlftpfs/0.9.2/curlftpfs-0.9.2.tar.gz
$ tar -oxzf curlftpfs-0.9.2.tar.gz
$ cd curlftpfs-0.9.2
$ ./configure CFLAGS="-g0 -O3 -DCURLFTPFS_O_RW_WORKAROUND"
$ make
$ sudo make install clean
$ cd

For testing in debugging mode do:
Code:
$ sudo kldload fuse.ko
$ curlftpfs -f -v -o debug,ftpfs_debug=3 username:password@ftp.example.com/ /mnt

Then in a second terminal session:
Code:
$ touch /mnt/test
$ rm /mnt/test
$ cp ~/curlftpfs-0.9.2/README /mnt/README
$ cat /mnt/README
$ rm /mnt/README
$ umount /mnt
 
fusefs-curlftpfs-0.9.2_6 from pkg (13.2-RELEASE-p10) doesn't work.

Do I have to resort to above manual install?
 
Back
Top