Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <4060BDC0.8070009@ianbrandt.com> Date: Tue, 23 Mar 2004 17:44:16 -0500 From: Ian Brandt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Definitely no sshd on FAT32? References: <40608855 DOT 8080605 AT ianbrandt DOT com> <40609FD8 DOT 5030103 AT ianbrandt DOT com> <20040323215100 DOT GY17229 AT cygbert DOT vinschen DOT de> In-Reply-To: <20040323215100.GY17229@cygbert.vinschen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Corinna Vinschen wrote: > The following checks are performed on the key file in the following order: > > - Not Windows NT? Yes -> Don't check permissions. I'm running Windows 2000, so this shouldn't catch. > - "ntea" switched on? Yes -> Check permissions. (Not applicable on FAT32) I don't have it set, and according to the docs it's off by default, and I'm on FAT32 anyway. > - statfs(key_file) fails? Yes -> Check permissions. I'm not familiar with this one, but I found a man page for statfs on my linux server. Unless FAT32 is represented by some cryptic name in the following file types (MSDOS_SUPER_MAGIC perhaps?), I'm guessing statfs fails on FAT32? File system types: ADFS_SUPER_MAGIC 0xadf5 AFFS_SUPER_MAGIC 0xADFF BEFS_SUPER_MAGIC 0x42465331 BFS_MAGIC 0x1BADFACE CIFS_MAGIC_NUMBER 0xFF534D42 CODA_SUPER_MAGIC 0x73757245 COH_SUPER_MAGIC 0x012FF7B7 CRAMFS_MAGIC 0x28cd3d45 DEVFS_SUPER_MAGIC 0x1373 EFS_SUPER_MAGIC 0x00414A53 EXT_SUPER_MAGIC 0x137D EXT2_OLD_SUPER_MAGIC 0xEF51 EXT2_SUPER_MAGIC 0xEF53 EXT3_SUPER_MAGIC 0xEF53 HFS_SUPER_MAGIC 0x4244 HPFS_SUPER_MAGIC 0xF995E849 HUGETLBFS_MAGIC 0x958458f6 ISOFS_SUPER_MAGIC 0x9660 JFFS2_SUPER_MAGIC 0x72b6 JFS_SUPER_MAGIC 0x3153464a MINIX_SUPER_MAGIC 0x137F /* orig. minix */ MINIX_SUPER_MAGIC2 0x138F /* 30 char minix */ MINIX2_SUPER_MAGIC 0x2468 /* minix V2 */ MINIX2_SUPER_MAGIC2 0x2478 /* minix V2, 30 char names */ MSDOS_SUPER_MAGIC 0x4d44 NCP_SUPER_MAGIC 0x564c NFS_SUPER_MAGIC 0x6969 NTFS_SB_MAGIC 0x5346544e OPENPROM_SUPER_MAGIC 0x9fa1 PROC_SUPER_MAGIC 0x9fa0 QNX4_SUPER_MAGIC 0x002f REISERFS_SUPER_MAGIC 0x52654973 ROMFS_MAGIC 0x7275 SMB_SUPER_MAGIC 0x517B SYSV2_SUPER_MAGIC 0x012FF7B6 SYSV4_SUPER_MAGIC 0x012FF7B5 TMPFS_MAGIC 0x01021994 UDF_SUPER_MAGIC 0x15013346 UFS_MAGIC 0x00011954 USBDEVICE_SUPER_MAGIC 0x9fa2 VXFS_SUPER_MAGIC 0xa501FCF5 XENIX_SUPER_MAGIC 0x012FF7B4 XFS_SUPER_MAGIC 0x58465342 _XIAFS_SUPER_MAGIC 0x012FD16D > - Does the file system support ACLs? (Shoud be only NTFS) > Yes -> "ntsec" switched on ? > Yes -> Check permissions This shouldn't catch. I tried nontsec just in case, but no change. > - Don't check permissions Well, we didn't get here. I tried passing 3 -d's to sshd, but the only added messages compared to what I posted originally were: debug2: read_server_config: filename /etc/sshd_config debug1: sshd version OpenSSH_3.8p1 So no help there. > Try to figure out what happens on your system. However, if you're > running 2K or XP, I don't see a reason to keep FAT32. You can convert > it to NTFS using the "convert" tool which is shipped with all NT versions. I lost a NTFS drive once to electrical failure, and I didn't have a current backup. It cost 5X as much to get the data recovered off the platters than if it had been FAT32. Of course it's my fault for not backing up regularly enough, but still. That and I'd have to trust that the conversion doesn't introduce any problems. Not a big deal, but if I don't have to do it I'd rather not. Thanks, Ian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/