NFS delete but no write!

[Guest ajcecil]

I am setting up NFS to share between my desktop and laptop machines. Both were on 9.1 - laptop now testing 9.2rc2. In both cases I can read items in the folder, I can delete items, but I cannot write items into the remote folder! This is true for both machines (fat32 partitions). I have searched for info but not found anything so far.

 

error message:

cp: cannot create regular file `test.txt': Operation not permitted

 

exports file:

/mnt/extra/Shared 192.168.2.0/255.255.255.0(sync,all_squash,anonuid=501,anongid=501,rw)

 

fstab:

192.168.2.100:/mnt/extra/Shared /mnt/ursa nfs rw,hard,intr,user,noauto 0 0

(manually mounted)

 

hosts.deny:

portmap: ALL

lockd: ALL

mountd: ALL

rquotad: ALL

statd: ALL

 

hosts.allow

portmap: 192.168.2.0/255.255.255.0

lockd: 192.168.2.0/255.255.255.0

mountd: 192.168.2.0/255.255.255.0

rquotad: 192.168.2.0/255.255.255.0

statd: 192.168.2.0/255.255.255.0

 

I appreciate any help anyone can give! Many Thanks... ajc

[Gowator]

Check the permissions on the mount directory.

The permissions will be inherited so if its no write once its mounted all files will be no write .

[Guest ajcecil]

Thanks for the reply - the permissions for the shared directories on both machines are on FAT32 partitions and therefore Root UID and GID with rwxrwxrwx (unchangeable)... I am squashing everybody to the UID and GID of the primary user (me) who has no problems writing to the folders locally.

 

The strange behaviour is that I can remotely delete files but not write - not consistent behaviour if it was a simple permission problem? Has anyone had problems with shares on FAT32 partitions? If I get time I will try on a Reiser partition with the UID I am squashing to. Thanks for the thoughts...

[Guest ajcecil]

I just realized you may have meant the permissions to the local mount directory - that is also UID Root with rwxrwxrwx...

[Gowator]

OK

3 things control mount permissions

 

1) The directory where they are mounted (say /mnt)

2) Options from the command line mount or automatic (-o rw)

3) limitations of the underlying filesystem (for example CD ISO9660)

 

All of the unix permissions are per user but this is a user ID not the name. Think of your name as an alias to a numeric ID.

 

If you type id <enter> you will see.

 

Check the file /etc/fstab. This holds the 'permanent' or persistent mounts that can be automatically mounted. If you mount them by hand then you can pass options at the command line to mount rw or ro

This might have something to do with FAT32 and how it handles delete/write privelidges.

 

Try and find the fstab enteries etc. and Ill take a look, otherwise what command are you mounting with?

[Guest ajcecil]

Thanks...

 

The permission in my fstab and exports are in the first post (both rw) - the partition containing the shared directory is mounted as setup by default by MD:

 

/dev/hda5 /mnt/win_d vfat iocharset=iso8859-1,codepage=850,umask=0 0 0

 

I have tried mounting the NFS share directly at boot time from fstab but if the other machine is shut off by accident it hangs the other badly (and I don't trust soft) - now I have fstab mounting as noauto and user so that I can mount as needed with a simple 'mount /mnt/ursa' which, I assume, automatically inherits rw permissions from the fstab entry. Both mount methods have the same problem.

 

In reference to your post:

> 1) The directory where they are mounted (say /mnt)

> 2) Options from the command line mount or automatic (-o rw)

> 3) limitations of the underlying filesystem (for example CD ISO9660)

 

a) partition on desktop with shared directory /mnt/win_d is rw by UID 501

B) directory on laptop where share is mounted is rw by UID 501

c) NFS share on laptop is mounted rw in fstab

d) exports file on desktop allows rw and squashes all users permissions to UID 501

e) I know of no underlying issues with FAT32...

 

Anyway - the permissions in the appropriate files should be failry obvious from what I have posted. It still doesn't seem to be the right problem if I can delete files. Surely linux user restrictions are solid enough to not allow me to delete files if I don't have write access!

[Guest ajcecil]

Well, in case anyone is interested in the continuing saga of NFS on FAT32 - the end message is DON'T. Unless you know something I don't...

 

I set up a directory /home/shared with owner root and rwx access to everyone (as was the previous one) - and it worked fine!

 

Even though the permissions were identical in both cases, the share on the FAT32 drive was not writeable - in fact it would create an empty document with the name of the written/copied file and then complain... not sure if anyone knows what that means?

 

So, it is now working fine on both Mandrake 9.1 (and a 486 I have set up using Debian 3.0 :-) ) but only as long as it is on a linux partition (Reiser in MD9.1 and EXT2 on Deb3.0).

 

Let me know if anyone comes up with an answer to the FAT32 question - as much as I would like to be MS free, it comes it handy sometimes.

[Gowator]

Hmm,

This seems to be something inherited from the FAT32 partiton then.

 

Or its inheriting something from the original FAT32 mount with vfat ???

 

Can you write to the Win partition directly from the box thats sharing it with the same uid???

[Guest ajcecil]

All operations on the local machine are fine as uid 501 - read, write and execute. The permissions on the FAT32 drives have never given any trouble when mounted on the local Mandrake installations.

 

In surfing around a little, it seems like NFS has occasional problems with FAT32 - although none that match what I am seeing. According to http://nfs.sourceforge.net

 

--

C4. I believe nfs will not export a fat32 partition under linux. Is that correct?

 

A. No, the FAT file systems can be exported, starting with the early 2.4 kernels, but if used extensively, they may cause grief. First, only those operations supported by the exported file system will be honoured. Operations such as "chown", "link", and "symlink" are not supported by these file systems, and will fail. Read/write/create etc., should be fine, as long as the files remain relatively unchanged.

--

 

It goes on to describe files manipulated by multiple clients losing track of the original file handle. This is obviously not the problem for me between only 2 machines.

 

Has anyone on the forum set up a successful NFS share of a FAT32 folder under Mandrake? I just got 9.2 final today and will test that out when I get the chance...

[Gowator]

More later,

As I said, its unreasonable to blame NFS/Linux for being unable to write to a proprietry filesystem.

 

However, as I pointed out early on this is really a problem of what permisssions are suported by FAT32!

 

The concept of a filesystem to linux/unix is not the same as the half assed concept under Win.

 

I don't actually have any Win partitions anymore, except when forced like compact flash and my USB devices etc. I get random problems with these, like permisions BECAUSE it doesn't understand permissions.

 

In unix a filesystem is independent of the OS, even though specific flavours like AIX or IRIX have their own filesystems the base is common. I don't know HOW FAT32 works, its closed source :D so we can only guess.

 

Think about it like this or THIS. Both the same file on FAT32! When these are exported from a Win server the win server part takes care of translating long/8.2 filenames using CIFS. So far as I know (and I don't play with Win very often) This is still inherited down to 2003 Server products. File ownership and the famous filelocking semantics of FAT/Win are mixed between the file system and the OS.

 

Think of it like a Win Modem or Win Printer. (See the connection ?)

 

 

 

On a complex network you can get round this. You need a buffer inbetween basically! i.e. Samba translates the FAT limitations, filename mangling etc.

 

You can mount a samba drive and then NFS export it. Samba then takes care of the permissions etc. using CIFS. You can do the same thing. First you export it as a samba share and smbmount the drive somewhere else.

 

Then you export the smb mounted drive as NFS

 

This then provides a CIFS layer between WIN32 and NFS.

 

This isn't strange in a UNIX perspective. It is not the job of NFS to do CIFS, etc. When you use other 'real' filesystems these are taken care of with the modules loaded or compiled in. i.e. EXT3 or reiserfs or jfs.

 

When you print a postscript file you send it through a postscrpt interpreter... it isn't the job of the program to know about postscript. Then its the job of your printer to understand postscript.

 

Hope this makes sense.

[pmpatrick]

I can finally write to FAT32 through nfs :) :) .

I'm not sure exactly what did it since I fiddled around so much in frustration. My /etc/exports file is virtually identical to yours and I could write to the FAT32 partitions but it would keep giving me error messages that I didn't have permission and would go ahead and write it anyway after insisting it wouldn't.

I think this was the critical thing - I changed the owner and group for the mount point on the server side to myself, i.e. an ordinary user/group:

 

# chown patrick:patrick /mnt/net

 

and set the anonuid and anongid to 501.

 

The stuff I'm sharing is an entire partition mounted on the server side through /mnt/net.

 

After that everything worked. Give it a shot; it's worth a try. Just change the owner/group of the FAT32 mount point on the server side to yourself.

Edit: Note, when you change the owner/group, make sure the FAT32 partition is mounted.