Different permissions when creating directories compared to SSH shell connection

[Sharky444]

If I connect to my Debian 9.5 linux server using a ssh shell and create new directories they get the permissions 755 by default:

mkdir /tmp/1 drwxr-xr-x 2 root 4.0K Oct 21 00:29 1/

When I use Filezilla, Total Commander (or any other tool that supports SFTP connections over SSH Port 22) to create directories, they are still created with the permissions of 755.

When I mount the filesystem into a Windows volume using the map network function with the parameter \sshfs\user@server.... and create a directory on that volume it gets permissions of 700 instead of 755.

drwx------ 2 544 4.0K Oct 21 00:33 2/

I'm using sshfs-win version 2.7 on Windows 10 Pro (tried also 3.2 beta, but that version doesn't work at all, no connection to server).

[er1z]

AFAIK, you have to specify umask manually (as -o option) but it's available only for mounts created via sshfs-win, not though add network share dialog.

[bolovanos]

Hi Bill, in advance thank you for trying to patch this gap in the market!

System Info:

Os Win 10 64b, 1803 Remote sshfs Debian 9

What are the steps to reproduce the problem?

I was able to connect throug Explorer and "Map network drive" menu. using

"\\sshfs\user@host\..\.." Than create Directory and file.

What was the expected result?

Newly created Directory drwxr-xr-x (755) Newly created File -rw-rw-r-- (644)

So umask=002.

What was the actual result?

Newly created Directory drwx------ (700) Newly created File -rwx------ (700)

By going through https://github.com/billziss-gh/winfsp/issues/138 and https://www.reddit.com/r/programming/comments/5zn0kz/winfsp_2017_fuse_for_windows_is_finally_here/ I have found some examples and refferences to sshf.exe.

So I have tested: On Host

>sshfs user@host: K: -o rellinks -o fstypname=SSHFS -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o idmap=user -o create_umask=002 -o umask=002 --VolumePrefix="\user@host" -o uid=-1,gid=-1
Enter passphrase for key 'C:\Users\bolovanos/.ssh/id_rsa':
hydrogen@192.168.0.100's password:
read: Connection reset by peer

On server /var/log/syslog

Nov  7 18:40:21 user sshd[22297]: Accepted password for user from 192.168.0.102 port 12293 ssh2
Nov  7 18:40:21 user sshd[22297]: pam_unix(sshd:session): session opened for user user by (uid=0)
Nov  7 18:40:21 user systemd-logind[412]: New session 1864 of user user.
Nov  7 18:40:21 user sshd[22303]: Received disconnect from 192.168.0.102 port 12293:11: disconnected by user
Nov  7 18:40:21 user sshd[22303]: Disconnected from 192.168.0.102 port 12293
Nov  7 18:40:21 user sshd[22297]: pam_unix(sshd:session): session closed for user user
Nov  7 18:40:21 user systemd-logind[412]: Removed session 1864.

Questions

1. Is it possible to create permanently mapped network drive using umask=002 which will persist after reboot - how?
2. How can I replicate mapping network drive in Explorer with umask=002 using cmd? Am I on the right way?
3. How can I suppress login with pregenerated key?
4. Why sshfs claims that Connection was reset by peer when on server is recieved disconnect from sshfs?

[er1z]

Have the same issue. @billziss-gh?

[billziss-gh]

Apologies for the late response. I was on vacation last week.

read: connection reset by peer

When SSHFS is started via "Map network drive" it is running in the Windows Service context and under the SYSTEM account. Furthermore the sshfs-win wrapper sets the PATH to be /bin (Cygwin) which is really \Program Files\SSHFS-Win\bin (Windows). So the PATH is different from the one you have when you run it via the command-line under your account.

In my experience the reason for the "read: connection reset by peer" and similar errors is usually due to the wrong ssh being picked up by sshfs. (NOTE: It may be worthwhile to use an absolute path to ssh and execv instead of execvp to avoid any such problems.)

Some people (including me) have had success using set PATH=C:\Program Files\SSHFS-Win\bin prior to invoking the sshfs command.

create_umask=002

@bolovanos You have correctly identified this option as the required option for setting permissions on new files (for the reasons explained in billziss-gh/winfsp#138). Unfortunately there is currently no easy way to add custom options to the "map network drive" command line. Your best bet is to modify sshfs-win.c and rebuild.

[er1z]

Since my last report I have reinstalled my OS and nothing changed — mounted via map network drive simply crashes after some files are being transferred (thousands) and I have to kill sshfs.exe, then execute net use….

Tried to alter PATH variable:

eRIZ@NABUCHODONOZOR C:\Program Files\SSHFS-Win\bin
$ sshfs eriz@192.xxxxxxxxx Y:
read: Connection reset by peer

eRIZ@NABUCHODONOZOR C:\Program Files\SSHFS-Win\bin
$ echo %PATH%
"C:\Program Files\SSHFS-Win\bin"

Using a full path to sshfs changed nothing. Any ideas? Seriously, the only way is to set up all msbuild chain and then use this?

[billziss-gh]

@er1z As I have mentioned elsewhere I do not know why you experience the problems you have described here and elsewhere. They do not happen for me and many other users.

This is an open-source and free project that is based on many other projects (WinFsp, SSHFS, SSH, Cygwin). While I wrote all of WinFsp, including the FUSE2 and FUSE3 layers as well as the patches to port SSHFS to Cygwin, I do not understand all of SSHFS or all of SSH or all of Cygwin. Furthermore I do not have the time to troubleshoot individual user's problems.

Please consider either:

• Learning enough about SSHFS, SSH and Cygwin to troubleshoot the problems you are experiencing yourself. I can certainly help with WinFsp and the Windows file system bits where I believe I have expertise.

• Use something else that works for you. I personally use Samba most of the time.

[er1z]

But it occurs on various computers, even with a different software configuration. It's just a different delay. I know it's opensource but I have no low-level experience so the only thing I can do is to report that thing happens.

The only thing I ask you is to at least try to reproduce on your own environment. I'm trying to find something faster than CIFS especially for thousands of small files.

PS. The fact others don't report this issue doesn't mean that it doesn't happen also.

[pavelxkrejci]

I have noticed that performance of sshfs-win for small files is relatively low compared to samba, but I use it for cross-platform convenience. There are a lot of moving components here that can make performance tuning difficult. For performance with small files you may want to try unison -batch, rsync (in ssh or wireguard tunnel) or commercial Aspera.

[er1z]

@pavelxkrejci — it's only a matter of tuning: http://www.admin-magazine.com/HPC/Articles/Sharing-Data-with-SSHFS

unison/rsync doesn't solve my problem.

[pavelxkrejci]

@er1z I don't understand what is your point with the tuning. Tuning as presented in the linked article means configuring settings for a very specific use case, making it worse or unreliable for other cases. As such you are free to do it yourself, but it's neither something generally applicable nor something that should be baked in.

Talking about small files, closest performance related chart from your article is Random Read IOPS, which showed little benefit from tuning. Highest increase there was from using insecure RC4 cipher, which beats the point of using ssh based tool in the first place.

The slowdown I am able to observe is more like high latency and is most likely due to multi-level translation of paths, APIs and calls through multiple components (win explorer, winfsp, sshfs, ssh, cygwin) there and back again from server. Transfer of large files is working pretty much ok for me - reaching max available bandwidth.

[er1z]

I have a virtual machine which has no exposed ports except host. Therefore I can do almost everything I want. SSH/SSHFS chain has everything I need including the speed.

All I want is to dig or point me how to prevent the communication process from crashing. And if you look carefully at the site I linked, you'll notice that IOPS ain't terrible.

[pavelxkrejci]

If the pre-canned solutions don't work, then your best course of action is to enable debug output both on client:

add following option to manual sshfs start as described here:

sshfs -osshfs_debug ...

and server, ie settings in sshd_config :

"LogLevel VERBOSE"

or parameters (max verbosity level example):

-vvv -o LogLevel=DEBUG3

and try to find log messages which correlate to your problem. You may need to decrease/increase debug level verbosity until you find something using "-vv -vvv -o LogLevel" parameters.

[er1z]

https://github.com/billziss-gh/sshfs-win/issues/59#issuecomment-420822452

[ygrob]

If I connect to my Debian 9.5 linux server using a ssh shell and create new directories they get the permissions 755 by default:

mkdir /tmp/1 drwxr-xr-x 2 root 4.0K Oct 21 00:29 1/

When I use Filezilla, Total Commander (or any other tool that supports SFTP connections over SSH Port 22) to create directories, they are still created with the permissions of 755.

When I mount the filesystem into a Windows volume using the map network function with the parameter \sshfs\user@server.... and create a directory on that volume it gets permissions of 700 instead of 755.

drwx------ 2 544 4.0K Oct 21 00:33 2/

Good catch. You are correct. SSHFS-Win is using an unusual default permission.

Generally speaking a SFTP client has to sent some permission when creating files or folders. Then, the SFTP server MAY apply a more restrictive mask using a umask. [The Linux umask only disables permissions it never adds permission as many people think]. Eventually the server file system may add an extra mask with ACL (see setfacl function) on files and folder created.

The good practice is for an SFTP client to be permissive enough and create files as mode 666 and folders as mode 777. Then the server may cuts the permission it doesn't want using umask and/or ACL.

For example you can see what WinSCP or Filezilla do when they create a file or folder, through the SFTP log file:

rivage@rivage:~$ tail -n 100 /var/log/auth.log | grep sftp | grep mkdir Mar 30 21:22:04 rivage internal-sftp[4073]: mkdir name "/home/rivage/dir/New directory" mode 0777

rivage@rivage:~$ tail -n 100 /var/log/auth.log | grep sftp | grep open [this is for files created] Mar 30 21:10:43 rivage internal-sftp[4073]: open "/home/rivage/dir/f3" flags WRITE,CREATE,TRUNCATE mode 0666

Now, this is how SSHFS-Win handle file and folder creation, it unfortunately forces GROUP and OTHER rights to 0:

rivage@rivage:~$ tail -n 100 /var/log/auth.log | grep sftp | grep mkdir Mar 30 21:22:28 rivage internal-sftp[4223]: mkdir name "dir/New folder" mode 0700

rivage@rivage:~$ tail -n 100 /var/log/auth.log | grep sftp | grep open [this is for files created] Mar 30 21:13:46 rivage internal-sftp[4223]: open "dir/New Text Document.txt" flags READ,WRITE,CREATE,EXCL mode 0700

This is not wrong, but for clarity, compliance and simplicity I really suggest SSHFS-Win to use 777 for folders and 666 for files as the other SFTP clients do by default Then the server restricts some rights if needed, this is the normal and clean way to proceed.

Thank you.

[ygrob]

@er1z As I have mentioned elsewhere I do not know why you experience the problems you have described here and elsewhere. They do not happen for me and many other users.

This a small SSHFS-Win issue not following the default standard of folder and file creation permission of SFTP, that is the same for FTP and Linux too. SSHFS-Win is applying 700 to files and folder too so most people never fall in any issue for single user environment. Note that 7 is also over permissive for file's for the user. It should be at most least 600 for files and 700 for folders; But the best is really to follow the default standard of 666 for files and 777 for folders as in Linux, the default permissions value is 666 for a regular file, and 777 for a directory. It is then the server's job to restrict that more if needed, not the client [but should be kept as an option in in SMB; VSFTP etc]

When I use Filezilla, Total Commander (or any other tool that supports SFTP connections over SSH Port 22) to create directories, they are still created with the permissions of 755.

Basically all the SSHFS software I tested and in fact any SFTP client, do apply the 777 upon folder creation and 666 upon files creation, then it often change to 755 as said but this is because of some umask or ACL, this is another story.

Just tried again with www.raidrive.com that can map SFTP to drive. Again, it generates 777 for folder and 666 for file as shown in the SFTP log file. Whereas SSHFS defaults to 700 for files (overpermissive for owner and over restricted for group and other) and does 700 for folders.

To see the default permission of SFTP client or SSHSF clients:

1. sudo nano /etc/ssh/sshd_config Subsystem sftp internal-sftp -l DEBUG
2. sudo service sshd restart
3. LOG OFF and LOG ON again with your SFTP credentials
4. tail -n 100 /var/log/auth.log | grep sftp

Checkout the permissions.

ps: impressive job with SSHS-Win and Winfsp, light and fast and easy to use. Thanks.

[billziss-gh]

BTW, it is now possible to specify the umask to use for newly created files and directories using the options create_umask, create_file_umask and create_dir_umask.

You can specify these options in the command line as detailed here. You can even change the default command line options in the registry for the sshfs key. Look for the CommandLine value under the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs registry key (in Win64).

[ygrob]

I knew for the switches but did not know for the HKLM, this extremely handy. You may want to mention that HKLM key in the readme.

This allows defaulting to any value while still using the 'Map Network Drive...' with higher-level \sshfs\ syntax of Windows/SSHFS-Win at the same time. That is cool and this totally solves Sharky444's issue. Thanks :-)

@Sharky444 : you need to edit the entry of the key above, then add the complementary bitwise value of the octal permission you are looking for, for file and folder creation. For example run regedit, go to the key above, search for CommandLine entry, you get something like

CommandLine = svc %1 %2 %U

change to

CommandLine = svc %1 %2 %U -o create_dir_umask=000 -o create_file_umask=111

log off (disconnect drive if any) and log on again. Now, you will have the standard 777 for folder creation (~000 == 777) and 666 for file creation (~111 == 666).

I just tested by curiosity, and confirm it works flawlessly. Note those umasks can also set permissions, unlike the 'Linux' umask that can only take permissions off.

Then you may want to add some ACL fine-tuning on the server's side like

$ sudo setfacl -R -d -m u::rwx,g::rwx,o::--- /home/sftpusers
so 777 is changed to 770 for example for folders created (and thus 660 for file). Note that ACL's are inherited in the sub folders when new folders will be created (alternatively, change directly the value create_dir_umask but this will enfore your rule to all the folders.. whereas ACL is nicer and wllo you a per folder's permission policy)

If you are using some more advanced multi-users sharing folders you may also want to add the SGID flag up on the server side like this: $ sudo chmod -R g+s /home/sftpusers/

So the group ID stays and remains the same as the one of parent's folder.

[Sharky444]

Guys, thank you very much for the persistence and finding a resolution to the problem! Now it works as intended.

Here is a reg file do it. Enter into notepad and save as sshfs_set_correct_permissions.reg, then double-click the file.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs]
"CommandLine"="svc %1 %2 %U -o create_dir_umask=000 -o create_file_umask=111"

[billziss-gh]

I knew for the switches but did not know for the HKLM, this extremely handy. You may want to mention that HKLM key in the readme.

@ygrob good idea and thanks for your help in these forums!

[orogenic]

I set the umask options on the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services\sshfs.k key since I'm using key authorization. Seems to have worked. Thanks for this tip!

[Lyneira]

Ran into this same issue when setting up the use of SSHFS-Win on a shared file server and spent some time looking into the possible cause. The mode for a newly created dir or file is determined starting on this line in fuse_intf.c. In the absence of options, context->umask should be 0 and the final Mode should be 0777, if it weren't for the call to FspPosixMapSecurityDescriptorToPermissions() which can set Mode.

In posix.c, Mode is set based on Access Control Entries (ACEs) retrieved from ACLs in SecurityDescriptor. I didn't get further than this, but based on this it looks like the mode for created files on the remote server depends on ACLs coming from the Windows client machine.

Setting create_file_umask and create_dir_umask options overrides the mode set by FspPosixMapSecurityDescriptorToPermissions() and allows for a workaround.

Relevant also to #180.