2

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.
Cobra_Fast
  • 650
  • 2
  • 8
  • 23
  • Show us the output of */proc/mounts*. – scai Feb 05 '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 05 '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 05 '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 05 '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
  • @StefanSeidel I've updated my question. The `ls -l` output is in the inital terminal quote. – Cobra_Fast Feb 19 '13 at 16:05

3 Answers3

3

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
Jenny D
  • 27,780
  • 21
  • 75
  • 114
noone
  • 31
  • 2
2

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.

zhenech
  • 1,492
  • 9
  • 13
0

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.

trent
  • 3,114
  • 19
  • 17
  • `# 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
  • I would think because Midnight commander is running as your user and the mount is running as root – trent Feb 11 '13 at 21:07
  • I'm working as root the entire time. – Cobra_Fast Feb 11 '13 at 21:11