Hi,
When a file is transferred via FTP to a Unix system, the default file permission attributes are 640.
When transferring a file from Mainframe to a Unix box using Co:Z SFTP the permission of the file changes to 666.
Could you please let me know if there is any way we could change the permission of the transferred file to 640 by default?
We can use chmod 640 <filename>, but wondering if there is any configuration that would allow this to be done by default.
Thanks & Regards,
Vasanth.S
File permissions when transmitting to unix boxes
Re: File permissions when transmitting to unix boxes
Please post a log of a test transfer with Co:Z SFTP with "-vvv" so that we can verify exactly what you are doing.
Re: File permissions when transmitting to unix boxes
Here is the JCL I use, SFTP is configured as a proc
The file is sent to Unix server. The file is being created by SFTP and the permission of the file TEST.TXT is 666.
Is there anyway to create the file with permission of 640, without using the chmod command.
Below is the -vvv log.
Code: Select all
//SPUFS05 EXEC SFTPP
//RUNSFTP.SFTPIN DD *
server="gotserver"
remoteuser="gotftp"
$coz_bin/cozsftp $ssh_opts -b- -vvv -i ~/u/KEYFILE \
$remoteuser@$server <<EOB
put //USERID.SORTIN //usr1/ftp/got/loaddata/TEST.TXT
EOB
//* Is there anyway to create the file with permission of 640, without using the chmod command.
Below is the -vvv log.
Code: Select all
1
CoZBatch[N]: version: 4.5.0 2017-07-26
CoZBatch[N]: Copyright (C) Dovetailed Technologies, LLC. 2005-2017. All rights reserved.
CoZBatch[I]: executing progname=login-shell="-/bin/sh"
Co:Z SFTP version: 4.5.0 (6.4p1) 2017-07-26
Copyright (C) Dovetailed Technologies, LLC. 2008-2017. All rights reserved.
Connecting to servername...
[67.373] debug3: connect_to_server arg=/bin/ssh
[67.373] debug3: connect_to_server arg=-oForwardX11 no
[67.373] debug3: connect_to_server arg=-oForwardAgent no
[67.373] debug3: connect_to_server arg=-oClearAllForwardings yes
[67.373] debug3: connect_to_server arg=-o
[67.373] debug3: connect_to_server arg=BatchMode=no
[67.373] debug3: connect_to_server arg=-o
[67.373] debug3: connect_to_server arg=ConnectTimeout=60
[67.373] debug3: connect_to_server arg=-o
[67.373] debug3: connect_to_server arg=ServerAliveInterval=60
[67.373] debug3: connect_to_server arg=-o
[67.373] debug3: connect_to_server arg=StrictHostKeyChecking=no
[67.374] debug3: connect_to_server arg=-obatchmode yes
[67.374] debug3: connect_to_server arg=-v
[67.374] debug3: connect_to_server arg=-v
[67.374] debug3: connect_to_server arg=-v
[67.374] debug3: connect_to_server arg=-i
[67.374] debug3: connect_to_server arg=//u/USERID/KEYFILE
[67.374] debug3: connect_to_server arg=-l
[67.374] debug3: connect_to_server arg=gotftp
[67.374] debug3: connect_to_server arg=-oProtocol 2
[67.374] debug3: connect_to_server arg=-s
[67.374] debug3: connect_to_server arg=--
[67.374] debug3: connect_to_server arg=lolztngbatch
[67.374] debug3: connect_to_server arg=sftp
[67.427] debug2: setting ssh _CEE_RUNOPTS=HEAP(12M,1M,ANYWHERE,FREE),ENVAR("_CEE_REALLOC_CONTROL=256K,25")
OpenSSH_5.0p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/zos_ssh_config
debug3: RNG is ready, skipping seeding
debug1: zsshSmfSetConnSmfStatus: SMF status is 0
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to lolztngbatch [IPADDRESS] port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: fd 4 clearing O_NONBLOCK
debug1: Connection established.
debug1: cipher_init: none from source OpenSSL
debug1: cipher_init: none from source OpenSSL
debug3: timeout: 59999 ms remain after connect
debug1: permanently_set_uid: 0/0
debug3: zsshGetpw: passwd name=USERID, uid=0, gid=0, dir=/, shell=/bin/sh
debug3: Not a RSA1 key file //u/USERID/KEYFILE.
debug1: identity file //u/USERID/GOTTNGBATCH_KEY type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_2.4
debug1: no match: Sun_SSH_2.4
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 4 setting O_NONBLOCK
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1
4-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast1
28-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast1
28-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1
4-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour
debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5
,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha2-256-96,hmac-sha2-512-96,hmac-sha1-96,hmac-md5
,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: de-DE,en-CA,en-US,es-ES,es-MX,fr-CA,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,es,fr,i-default
debug2: kex_parse_kexinit: de-DE,en-CA,en-US,es-ES,es-MX,fr-CA,fr-FR,it-IT,ja-JP,ko-KR,pt-BR,zh-CN,zh-TW,es,fr,i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: mac_setup_by_id: hmac-md5 from source OpenSSL
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: mac_setup_by_id: hmac-md5 from source OpenSSL
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 995/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: __catgets: NLS setup complete (1), using message catalog openssh.cat
FOTS2274 Warning: Permanently added 'gottngbatch,IPADDRESS’ (RSA) to the list of known hosts.
debug2: bits set: 1035/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: cipher_init: aes128-ctr from source OpenSSL
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: cipher_init: aes128-ctr from source OpenSSL
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: //u/USERID/CSS_GOTTNGBATCH_KEY (0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: //u/USERID/CSS_GOTTNGBATCH_KEY
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentication succeeded (publickey).
debug2: fd 6 setting O_NONBLOCK
debug2: fd 7 setting O_NONBLOCK
debug2: fd 8 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug2: fd 4 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 1025184
[69.973] debug2: Remote version: 3
Connected to gottngbatch.
Connection established, local_addr=IPADDRESS local_port=4333 remote_addr=IPADDRESS remote_port=22
[70.284] debug3: Sent message fd 7 T:16 I:0
[70.286] debug3: SSH_FXP_REALPATH . -> /export/home/gotftp size 0
cozsftp> put //USERID.SORTIN //usr1/ftp/got/loaddata/TEST.TXT
Uploading //USERID.SORTIN to //usr1/ftp/got/loaddata/TEST.TXT
ZosSettings[I]: Transfer options: blksize=6233,lrecl=256,mode=text,overflow=trunc,recfm=vb,trim,trtab=STANDARD
ZosDataset[I]: Opening dataset USERID.SORTIN for read with options: shr
[70.337] debug3: Sent message SSH2_FXP_OPEN I:1 O:x1a P://usr1/ftp/got/loaddata/TEST.TXT
[70.340] debug3: Sent message SSH2_FXP_WRITE I:2 O:0 S:39
[70.341] debug3: SSH2_FXP_STATUS 0
[70.341] debug3: In write loop, ack for 2 39 bytes at 0
ZosDataset[I]: Closing dataset //USERID.SORTIN - 3 records read, 39 bytes sent
[70.345] debug3: Sent message SSH2_FXP_CLOSE I:2
[70.346] debug3: SSH2_FXP_STATUS 0
debug2: channel 0: read<=0 rfd 6 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
debug3: channel 0: close_fds r -1 w -1 e 8 c -1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.7 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
CoZBatch[I]: returning rc=exitcode=0
Re: File permissions when transmitting to unix boxes
The trace confirms that the Co:Z SFTP client is not explicitly setting the mode of the file.
This is happening on your sftp server.
So, the default umask for your sftp server is different from the ftp server that you were using.
I don't know what sftp server that you are using, but if you are using recent versions of OpenSSH, you can set the desired file umask like this:
https://serverfault.com/questions/70876 ... -with-sftp
Note: a umask of 000 is not a typical default, so it could be that your sftp server has changed the default value.
This is happening on your sftp server.
So, the default umask for your sftp server is different from the ftp server that you were using.
I don't know what sftp server that you are using, but if you are using recent versions of OpenSSH, you can set the desired file umask like this:
https://serverfault.com/questions/70876 ... -with-sftp
Note: a umask of 000 is not a typical default, so it could be that your sftp server has changed the default value.
Re: File permissions when transmitting to unix boxes
Thank you very much for your reply.
The server is a Unix server and I think it is the default SFTP server on Unix. Sorry I am not familiar with Unix.
Our Unix programmer here and he too suggested your solution with the umask.
Thanks again.
Vasanth.S
The server is a Unix server and I think it is the default SFTP server on Unix. Sorry I am not familiar with Unix.
Our Unix programmer here and he too suggested your solution with the umask.
Thanks again.
Vasanth.S