Did I accidentally delete files? How can I recover them?

$ sudo sshfs lab@ipaddress:/home/lab/Desktop /home/usr/labDesktop [sudo] password for usr: The authenticity of host 'ipaddress (ipaddress)' can't be established. XXX key fingerprint is XXX. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes lab@ipaddress's password: 

This establishes a sshfs connection: for user root on server B, the directory /home/usr/labDesktop allows access to server A's /home/lab/Desktop directory with the access rights of user lab on server A.

Specifically, this does not mean user lab on server B would have any access to /home/usr/labDesktop.

$ cd labDesktop -sh: 44: cd: can't cd to labDesktop 

So you cannot cd to the directory as your regular user lab. This is as expected.

$ sudo sshfs lab@ipaddress:/home/lab/Desktop /home/usr/labDesktop lab@ipaddress's password: read: Interrupted system call 

Trying to mount it again fails, probably because it's already mounted.

$ fusermount -u /home/usr/labDesktop fusermount: entry for /home/usr/labDesktop not found in /etc/mtab 

More specifically, there is no mount entry for /home/usr/labDesktop that the user lab would be able to unmount, because the initial mounting was done by user root, not lab. So this command does nothing.

$ rm -r labDesktop rm: cannot remove 'labDesktop': Permission denied 

Because the mount was done by user root, the user lab has no write access to labDesktop at all. This is as expected.

$ sudo rm -r labDesktop rm: cannot remove 'labDesktop': Device or resource busy 

This command says: "As user root, delete everything within directory labDesktop, including the directory itself." This is the mistake.

Since server A's directory is perfectly accessible for user root through the sshfs mount, the command will delete everything within the directory. But deleting the directory itself fails, because the directory is actually a mount point. However, that error message only appears after everything else within has already been deleted.

$ mount | grep /home/usr/labDesktop lab@ipaddress:/home/lab/Desktop on /home/usr/labDesktop type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0) 

This confirms that server A's directory is indeed still mounted and accessible to root only.)

$ fusermount -u /home/usr/labDesktop fusermount: entry for /home/usr/labDesktop not found in /etc/mtab $ fusermount -uz /home/usr/labDesktop fusermount: entry for /home/usr/labDesktop not found in /etc/mtab 

User lab has no permission to unmount something root has mounted for themselves.

$ sudo umount /home/usr/labDesktop 

By using sudo, you issue the unmount request as user root, and so it will succeed.

$ rm -r /home/usr/labDesktop 

And after a successful unmount, you can delete the labDesktop directory, because it is now just a regular empty directory.

(A rmdir /home/usr/labDesktop would have been sufficient. It would be a good habit to use rmdir whenever you expect to be deleting an empty directory, as it would do nothing and produce an error message if the directory was unexpectedly non-empty.)

1. Could this sequence of commands have caused the files on Server A to be deleted?

Definitely, once you ran the rm -r command as the same user that had done the mount on local server B, and the remote user specified in the sshfs command was presumably the owner of the directory on the remote server A, so was expected to have full access.

With sudo, you had full access to the mount, and so server B did exactly what you asked and deleted everything it could access within the mount point.

2. Is there any way to recover them?

Command-line rm will not "move files to trash can". It is a command to actually delete the specified file(s) immediately.

Do you have good backups of that directory of server A?

If not, and you want to attempt to recover deleted files, then it's important to stop using that filesystem on server A immediately so the blocks that used to contain the deleted files won't get overwritten with newer data. The filesystem should be unmounted on server A, and then appropriate data recovery utilities could be run on it. Any recovered files should be saved to some other filesystem: it is important that the filesystem with the lost data is not modified any further until no further recovery actions are needed/worthwhile.

If the filesystem on server A is on a SSD, it is also important to ensure no periodic TRIM optimizations are executed on that entire SSD until recovery operations are concluded. If the filesystem gets TRIMmed, any deleted files will most likely be irrevocably gone.