我有一个带有 hetzner.de 的专用 Ubuntu 服务器。hetzner 还提供了一个单独的备份空间,可通过samba/ftp/sftp/scp.
在他们关于备份的支持文档中,提到了以下行。
“直接使用 rsync 是不可能的。但是可以使用 smbfs、sshfs 或 ftpfs 在本地安装备份空间,从而允许有限地使用 rsync。要充分利用 rsync(例如使用硬链接的增量备份),图像文件必须创建,应通过环回挂载。”
我想将 rsync 与使用硬链接的增量备份一起使用。我认为环回是指http://en.wikipedia.org/wiki/Loop_device。任何人都可以帮助我如何从网络位置创建图像?
我正在尝试对驱动器进行网络备份。这个过程有两台机器。
电脑1:
电脑2:
我在 PC2 上执行以下操作:
sshfs root@PC1:/dev ~/Desktop/netdisk/
Run Code Online (Sandbox Code Playgroud)
安装得很好。我在 ~/Destkop/netdisk/ 中有可用的 sdb。下一步:
sudo dd if=~/Destkop/netdisk/sdb | gzip -c > ~/Destkop/ddbackup/image.gz
Run Code Online (Sandbox Code Playgroud)
产生错误:
dd: opening `netdisk/sdb': Permission denied
Run Code Online (Sandbox Code Playgroud)
当我检查 sdb 的权限时:
brw-rw---- 1 root disk 0, 0 Jan 3 10:47 sdb
Run Code Online (Sandbox Code Playgroud)
由于我以root@ PC1 的身份通过 ssh 连接到 PC1,这是否意味着我对作为 sshfs 挂载的文件具有 root 访问权限?
从这个例子看来它没有,这里有我遗漏的概念吗?
mount -o remount,ro在sshfs坐骑中的等价物是什么?
我知道的唯一方法是fusermount -u使用sshfs -o ro.
当我从 bash 运行我的 SSHFS 连接脚本时,一切正常。
但是,当我使用该expect实用程序运行相同的脚本时,当我尝试访问文件夹安装位置时出现以下错误:
Transport endpoint is not connected
Run Code Online (Sandbox Code Playgroud)
这是我的期望脚本:
#!/usr/bin/expect -f
spawn standard_sshfs_connection_string_or_script
expect "password: "
send "my_password\r"
Run Code Online (Sandbox Code Playgroud)
问:有什么想法吗?
笔记:
fusermount -u mount_locationspawn创建新进程的事情,也许 sshfs 进程过早关闭?(有没有办法确保 sshfs 进程保持打开状态?)我的朋友有一个公共服务器,他给了我 SFTP 读取权限。我已经使用命令成功地将它安装在 Mint 17 中
sshfs user-name@file-server:/location/I/want /mount/point/I/want -o port=portNumber
Run Code Online (Sandbox Code Playgroud)
现在我想与我住在一起的人共享文件夹,但我不希望他们自己设置任何东西。相反,我希望他们看到包含 SFTP 共享的网络共享。
我已经使用 Nautilus 设置了一个共享文件夹,并在其中设置了我的挂载点。它在我的本地机器和我自己的用户上运行良好。但是,当我的朋友将他们的 Windows 计算机指向我的共享文件夹时,它看起来是空的。
我如何让他们看到坐骑?
在 Fedora 21 当前补丁上,在本地 LAN 环境中,我使用 sshfs 挂载了 2 个文件系统。远程服务器位于可靠的 LAN 网络上,正确设置了 ssh 密钥以进行无密码登录。
所以我在我的主目录(这是一个本地文件系统)中创建一个空目录,挂载:
sshfs -o default_permissions me@remoteserver:/mntpoint /home/me/mountdir
Run Code Online (Sandbox Code Playgroud)
连接工作正常,非常稳定,性能良好,没有投诉。然后可能是本地机器重新启动或发生了一些意想不到的事情,因此连接被不正常地中断了。
重新启动,重新启动,重新尝试后,上述相同的命令将无限期挂起。如果我控制 -C 它并 fusermount -u 它,它似乎已清理,但仍然无法重新安装。但奇怪的是:如果我在我的主目录中指定一个新的挂载点,它会再次完美运行(相同的远程点)。再次完美运行,直到发生某些事情,我必须重新开始。
重新启动本地机器不会清除它。挂载目录被验证为空,我什至删除了挂载点目录并重新创建了相同的名称......不。
最终经过一些触发,我可以回到旧的挂载点。所以我最终有大约 3-4 个目录,例如:
/home/me/mount.1
/home/me/mount.2
...
/home/me/mount.4
Run Code Online (Sandbox Code Playgroud)
在我回到 mount.1 之前。
有时它第一次工作,特别是如果我正确卸载它,但大多数时候它不会。
关于如何清除 sshfs 持有的任何想法。我在任何/etc文件中都找不到任何内容。
完全沮丧。
我最近开始在我的笔记本电脑上使用 VPN 服务器。现在一切都通过它路由,包括我的 SSHFS 挂载和 SSH shell 到/从我的 FTP 服务器。因此,它现在非常缓慢且无响应。
除了所有与 SSH 相关的任务外,是否仍然可以“全局”使用 VPN?(只有笔记本电脑使用 VPN 连接,而不是 FTP 服务器)
拱形Linux。
当挂载由任意非 root 用户建立时,允许所有本地用户访问 sshfs 挂载的最佳实践方法是什么?(当然,访问将根据文件权限。)
如果allow_other正确指定了挂载选项,是否可以在 /etc/fstab 中指定任意用户以及该用户的 ssh 密钥对?
我考虑使用类似的东西通过 fstab 自动挂载 sshfs:
joe@fileserver:/shared/Docs /shared/Docs fuse.sshfs x-systemd.automount,_netdev,user,identityfile=/home/joe/.ssh/id_rsa,allow_other,default_permissions 0 0
Run Code Online (Sandbox Code Playgroud)
我在 /etc/fuse.conf 中取消了“user_allow_other”挂载选项的注释。假设 sshfs 安装现在可以为用户“joe”正常工作。
我希望其他用户(例如,mary、tim)能够访问 /shared/Docs,这由标准文件权限决定。
使用 sshfs 实现此目的的最佳实践方法是什么?从 nfs 转换到 sshfs 时需要注意哪些注意事项?
在 nfs 下,root 帐户挂载了共享。使用 sshfs 我不能使用 root 帐户,因为文件服务器不允许 root 进行 ssh 连接。
文件服务器运行 Arch Linux。客户端是 Arch 或 Ubuntu。
关于 FUSE GitHub 页面,我有一些问题:
下面是否意味着SSHFS报价确实,如果支持的ACLdefault_permissions是不使用?
这是否意味着如果需要 ACL 支持和适当的安全性,既不应该default_permissions也不allow_other应该用作挂载选项?(很明显,allow_other没有default_permissions.不应该使用。)
如果 #2 是正确的,这是否意味着 SSHFS 挂载default_permissions和不挂载allow_other都会正确地将服务器的文件权限和 ACL 传递给客户端?
来源:GitHub - libfuse/libfuse:FUSE(用户空间中的文件系统)接口 https://github.com/libfuse/libfuse
如果您打算使用 allow_other 挂载选项,请注意 FUSE 有一个未解决的安全漏洞: 如果没有使用 default_permissions 挂载选项,只要被访问条目的 inode 存在于内核缓存中,文件系统对目录条目执行的第一次权限检查的结果将被重新用于后续访问 -即使权限已更改,即使后续访问是由不同的用户进行的。如果文件系统只能由挂载用户访问(无论如何都可以完全访问文件系统),则这无关紧要,但是当其他用户被允许访问文件系统时(因为他们可以利用它对文件系统执行操作),这将成为一个安全问题他们实际上没有权限的文件系统)。
这个错误需要在 Linux 内核中修复,并且自 2006 年以来就已经存在,但遗憾的是尚未应用任何修复。如果您依赖 FUSE 文件系统的正确权限处理,唯一的解决方法是使用default_permissions(当前不支持 ACL),或者完全禁用目录条目属性的缓存。
在我的环境中,所有客户端和服务器都运行 Linux,并且都使用 BTRFS(支持 ACL)。所有 GUID 和 UID 都匹配。
allow_root
此选项类似于allow_other,但文件访问仅限于安装文件系统和root 的用户。此选项和allow_other 是互斥的。
来自 mount.fuse(8)
如果平台很重要,请假设我使用的是最新版本的 FUSE 和 Linux。
sshfs ×10
fuse ×2
linux ×2
mount ×2
security ×2
ssh ×2
acl ×1
arch-linux ×1
bash ×1
expect ×1
linux-mint ×1
loop-device ×1
permissions ×1
remote ×1
rsync ×1
samba ×1
sftp ×1
vpn ×1
windows ×1