I'm new to davfs so please excuse me if this issue has been discussed previously.
I'm using davfs2 to post files from a SuSE Linux box to an Oracle Portal and sometime encounter a situation where the resultant file is zero bytes in length and has a date of 31-Dec-69.
Has anyone seen this issue before and does anyone have a fix?
If I can provide more information, please let me know.
Thanks in advance.
it might be a "locked null resource". This will occur when someone takes a lock on the server (to reserve the name) but has not yet uploaded the file. This "locked null resources" will have length zero and no valid attributes associated.
But to be sure, and as there have been a lot of changes to the code, some more information would be usefull:
- what is the exact version of davfs2? You will get it using the command "/sbin/mount.davfs -V".
- From what source did you get it (in case it is a patched version from some distribution).
- What are the situations when this happens?
- What davfs2 related commands did you issue before?
- Was this file created by you using davfs2?
- Does the file exist on the server and what are it's size and creation date? (Maybe you can access the server with an ordinary browser to get this information.)
Here's the info that you requested:
/sbin/mount.davfs: davfs2 0.2.8 <http://dav.sourceforge.net>
I got davfs2 from SourceForge.
I cannot reproduce this problem at will, it happens sometimes and not other times.
My process for creating the files is as follows:
on SuSE machine, generate tar file (some are large, up to about 650MB), mount davfs on /mnt/dav, copy tar file from SuSE to /mnt/dav/....., I check the return value from the cp command and check for size (if [ -s $filename ]), both return success.
When the zero-byte file gets created, it shows that the user who has /mnt/dav mounted is the owner, the size is 0 and the creation date is always 31 Dec 1969.
the problem most propably arises when davfs2 can not save the file on the server (maybe the connection is down or the server refuses to accept the file; maybe the file is too big?).
To understand the problem, why davfs2-0.2.8 can not solve the problem, and how davfs2-1.0.2 tries to avoid data loss, I will have to explain what is going o:
When you issue a copy command, davfs2 mount.davfs will not just get one command, but gets a sequence of commands from the kernel:
mount.davfs will try to get the new file from the server and usually report back that the file does not exist. This is to prevent unintended overwriting an existing files.
mount.davfs will create an empty file locally. This local file is intended to be a buffer. mount.davfs will also request a lock for the new filename from the server.
mount.davfs will open the local file (buffer) and return an file handle to the kernel.
Now copy and kernel will write the data into this local file. mount.davfs is not involved in this step.
When data is written into the local file, this command tells mount.davfs to close the file. mount.davfs will now store the file on the server and release the lock. If no error occurs the new file will exist on the server and will be visible if you do 'ls'.
If an error occurs in the last stage and mount.davfs can not store the file on the server and release the lock, there is not much mount.davfs can do. It reports an error to the kernel, but most applications ignore errors when closing a file. mount.davfs will remove the local file, as it does not know, how to handle this problem.
Now on the server the file is locked but not existent. This "locked null resource" will be reported by ls as file with length zero and Unix time value zero. Unix time zero is the same as 1 Jan 1970 00:00. Your system is just one second early (31 Dec 1969).
The new version of davfs2, 1.0.2, tries to solve this problem:
- it will not list "locked null resources" in directory listings
- if it can't save files back to the server, it will store a local backup file. From time to time it will retry to store the file back. If this will fail, it will store the local backup file permanently, even if you unmount. So data loss will be avoided and you can store the file later, when the connection to the server comes up again.
davfs2-1.0.2 is not yet widely tested (beta), but it would be nice if you test it and report your experience.
I've downloaded and installed davfs2, 1.0.2 and am having issues attempting to mount as a regular user. As root, mounting is fine. As myself, I get this message:
/sbin/mount.davfs: You can't mount into another users home directory.
Linux mcdonald 2.4.21-40.ELcustom #2 SMP Fri Jun 16 12:34:02 EDT 2006 i686 i686 i386 GNU/Linux
ls -l /usr/local/sbin/mount.davfs
-rwsr-xr-x 1 root root 3141411 Apr 30 16:13 /usr/local/sbin/mount.davfs
http://servername.coresys.com:7778/dav_portal/portal/product /mnt/dav davfs noauto,user 0 0
As soon as I get this working, I'll attempt to recreate the problem for which this thread was started and report my results. What options do you suggest I use for the zero-byte problem resolution?
when mounting as non-root user, davfs2 checks whether you are using a mount point that lies in another users home directory. davfs2 will not allow this.
But there is a bug in davfs2-1.0.2 that causes this error, if any user in /etc/passwd has no home directory at all.
I fixed this bug in the CVS repository.
Until we do a new release, you have 3 option to work araund this bug:
1. You may get the sources form CVS and build davfs2. (It may take some time until changes in CVS will be publically available. So please check for an entry in Changelog with date 2006-06-17).
2. You may use a mount point that lies within your home directory (e.g. /home/patrick/dav). In this case the buggy check for foreign home directories will be avoided.
3. You might assign a non existent directory (e.g. /nonexistent) to users without home directory in /etc/passwd. But this is the least recommended option as it requires to change system configuration files.
I don't believe that my problems are caused by any of the issues that you pointed out as potential problems. Here's what I have:
ls -ld /mnt
drwxrwxrwx 6 root root 4096 Jun 2 10:15 /mnt
ls -ld /mnt/dav
drwxrwxrwx 2 root root 4096 Mar 6 14:03 /mntdav
uid=592(schipper) gid=101(users) groups=101(users),1143(icb),1137(stint)
grep schipper /etc/passwd
(not there, login info is from NIS)
I will attempt to download the source, build it and try again.
I've downloaded and installed the binary version 2-1.1.1 and am still seeing the same issue:
/sbin/mount.davfs: You can't mount into another users home directory.
"/" is the home directory of nobody.
> "/" is the home directory of nobody
Does this mean:
- There is no user that has home directory "/"
- This is the home directory of user "nobody"
The background: as an additinal security precaution davfs allows ordinary users only to use mount points that are either
- withing their own home directory
- or in an directory like /mnt, that should not be the home directory of anybody , not even of nobody.
Did you try to use a mointpoint in your home directory?
Examination of the passwd files shows that teh user nobody has a home directory of "/".
What I don't understand is that I'm attempting to mount /mnt/dav. /mnt is not the home directory of any user.
I'm sure that having the mountpoint in my home directory would work, but that solution is not a good one since multiple users on this machine need to mount.
I've commented out the code in mount_davfs.c that performs this check and will experiment with that for a while.
it seems that the root of the file system on your system is indeed the home directory of user nobody.
I do not unterstand what should be the use of this. If you have information about this (maybe in the documentation of your distribution? Suse?), please tell me.
Currently this means that ordinary users can only use mount points within their own home directory, as everthing else is in the home directory of somebody else, e.g. user nobody. I think this is in most cases not really a restriction, when the mounted davfs2 file system is only used by the mounting user anyway.
But when I get information, that making the file system root the home directory of user nobody, is a reasonable system configuration, I will have to rearrange the security restrictions in davfs2.