Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have mounted a FTP backup solution to /opt/backup and it seems to be write only (even as root, as shown).

# touch foo
# ls -l
-rw-r--r-- 1 root root 0 Feb 19 16:00 foo
# cat foo
cat: foo: Permission denied
# rm foo
# ls

Mountpoint looks like this:

drwxr-xr-x  1 root fuse 1.0K Jan  1  1970 /opt/backup

Fstab line is:

curlftpfs#user:pass@user.backup.tld /opt/backup     fuse    allow_other,uid=0,gid=116,noatime       0 0

GID 116 is the fuse group.

PS: It's not an issue with the FTP server, since it works fine in midnight commander.

What is going wrong here?

Edit 2013-02-19:
Debugging curlftpfs (with -f -d flags) gave the following output when trying to cat:

unique: 19, opcode: OPEN (14), nodeid: 3, insize: 48, pid: 30167
open flags: 0x8000 /foo
ftpfs: operation ftpfs_open failed because Permission denied
   unique: 19, error: -13 (Permission denied), outsize: 16

Again, using an client program such as midnight commander, no such problem occurs.

Edit 2013-06-25
I have now changed to using CIFS, which works properly.
This is obviously not a solution, though.

share|improve this question
Show us the output of /proc/mounts. – scai Feb 5 '13 at 11:58
@scai curlftpfs#ftp://user:pass@user.backup.tld/ /opt/backup fuse rw,noatime,user_id=0,group_id=0,allow_other 0 0 – Cobra_Fast Feb 5 '13 at 12:05
Seems to be mounted writable. Does this also occur with other FTP servers? Does it also occur if you mount by hand instead of using fstab? – scai Feb 5 '13 at 12:46
@scai I currently don't have any other servers at hand, but it's the same problem when I mount by hand. – Cobra_Fast Feb 5 '13 at 13:11
You can run curlftpfs user:pass@user.backup.tld /opt/backup -f -d to run it in debug mode and see what's going on. Also, ls -l after touch foo will be helpful. – Stefan Seidel Feb 18 '13 at 14:30

Just to solve this: As someone mentioned before, the problem was related to ipv6, to fix it simply add "ipv4" to the parameters to disable ipv6:

# cat /etc/fstab

curlftpfs#SERVER /mnt/ftp-backup fuse disable_eprt,noauto,nodev,noexec,ipv4
curlftpfs#SERVER /mnt/ftp-backup fuse.curlftpfs disable_eprt,noauto,nodev,noexec,ipv4
share|improve this answer

Are you using IPv6? I just had the very same problem and it was (sadly) related to my connection to the FTP server being over IPv6.

After mounting with -u ipv4, everything was fine. tcpdump suggested that cURL and the remote FTP server could not properly initiate a passive FTP connection over v6.

share|improve this answer

Is it just a UID mapping problem? If you open up the permissions on the directory so that anyone can write to it does that solve the problem? If so I'm guessing root is being mapped to the remote system as nobody.

share|improve this answer
# chmod 777 /opt/backup chmod: changing permissions of '/opt/backup': Operation not permitted – Cobra_Fast Feb 11 '13 at 16:37
Sorry should have been more specific do this on the hosting machine not the client machine – trent Feb 11 '13 at 18:01
The only access I have to the hosting machine is said FTP. – Cobra_Fast Feb 11 '13 at 18:09
My best guess is that your being mapped as nobody ... you may need to ask the admin of the hosted machine to check. When you put a file out just ask for him to return the ls -l so you can see how you are being mapped. – trent Feb 11 '13 at 18:32
Everything works fine when I use for example Midnight Commander to access the FTP. As far as I'm concerned it has to be an issue with urlftpfs on my end. – Cobra_Fast Feb 11 '13 at 18:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.