# Powerpoint 2007 file access from samba



## com160 (May 28, 2008)

I save a powerpoint file to a samba network share with 2003 or 2007 as a ppt(2003) file logged in as user abc001. when I try to open it as a different user(abc002) in 2003 it works fine, but if i open it with 2007 it fails with the error "powerpoint was unable to open or save the document. please ensure that you have access privileges to read or write the document and that it is not encrypted".
if abc002 copies the document and pastes it to the same place (takes ownership) the document will then open in 2007. 

I have tried it on a windows 2003 share it there is no problem.

I have added the share to PowerPoint Options, Trust Center, Trust Center Settings, Trusted Locations.

I have tried with word, excel and access file and they wall work in the samba share.

I have tried it with different users on a different share and get the same results.

at the moment only 2 users has come across the problem but there will be more when we migrate everyone(6000 users) to 2007. 
can anyone suggest anything for opening a powerpoint 2003 file that you do not own, but do have permissions to from a samba share with powerpoint 2007.

Mike


----------



## rhart (Jun 22, 2009)

Just in case this is still an issue for anyone. I have a linux disk mounted to my samba server and whenever I open a powerpoint from that disk through samba I get the same problem. I added the "no_root_squash" option to the disk export and the problem is fixed.


----------



## afluegel (Apr 20, 2010)

The problem with Powerpoint 2007 and probably other Microsoft applications is, that when reading a document file it is writing the read time (atime in Unixish) into the file thus modifying the modification timestamp in the inode (mtime). Now to obfuscate the write operation the Microsoft application tries to reset the modification timestamp to the value it had before. With Windows Servers this seems to work. Seems, that when the file is writable, Windows considers the modification and read timestamp writable, too. On Unix it's not necessarily so: to be able to modify timestamps, the file must be owned by the current user (see utimes(2) ). Thus the Microsoft application cannot open files, that are readable and writable, but do not belong to the current user. This conflict is not resolvable except with adding filesystem entry attributes to allow inode modifications explicitely. This would require modifications in the filesystem implementations. Otherwise to enable Microsoft applications to open files via Samba, that do not belong to the current user, but are readable (and probably writable, too) for him, this workaround implemented here can help: If the file is writable but does not belong to the current user and thus utimes(2) fails, ignore the failure, return 0 and reset errno to the value it had before. This is done by compiling the following source code to a shared object and pointing the environment variable LD_PRELOAD in the samba start script to the created shared object before starting the smbd. Assuming the c-code below is in a file utimes_windows.c , compile it like this:
gcc -fPIC -c -O2 utimes_windows.c
ld -G -o libutimes_windows.so -s utimes_windows.o
The created shared object is libutimes_windows.so. This is utimes_windows.c:
/*
* $Source$
* $Id$
*/

#define	const	/**/

#ifdef	linux
#define	_GNU_SOURCE	1
#endif

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <utime.h>
#include <dlfcn.h>
#include <string.h>
#include <errno.h>

/* A problem with some Microsoft applications is, that when reading a document file
* they are writing the read time (atime in Unixish) into the file thus modifying
* the modification timestamp in the inode (mtime). Now to obfuscate the write
* operation the Microsoft application tries to reset the modification timestamp to
* the value it had before. With Windows Servers this seems to work. Seems, that
* when the file is writable, Windows considers the modification and read timestamp
* writable, too. On Unix it's not necessarily so: to be able to modify timestamps,
* the file must be owned by the current user (see utimes(2) ). Thus the Microsoft
* application cannot open files, that are readable and writable, but do not belong
* to the current user. This conflict is not resolvable except with adding filesystem
* entry attributes to allow inode modifications explicitely. This would require
* modifications in the filesystem implementations. To enable Microsoft applications
* to open files via Samba, that do not belong to the current user, but are readable
* (and probably writable, too) for him, this workaround implemented here can help:
* If the file is writable but does not belong to the current user and thus utimes(2)
* fails, ignore the failure, return 0 and reset errno to the value it had before */

int
utimes(char * filename, struct timeval * times)
{
static int	(*funchand)(char *, struct timeval *) = NULL;

struct stat	statb;
int	r, r_stat, fd, s_errno;

if(!funchand){
funchand = dlsym(RTLD_NEXT, "utimes");	/* obtain handle to original utimes */
if(!funchand)
return(-1);
}

s_errno = errno; /* save errno for possible restoring later */

r = funchand(filename, times); /* call the original utimes() */
if(r < 0 && (errno == EACCES || errno == EPERM)){	/* failure: not allowed */
r_stat = stat(filename, &statb); /* stat for checking ownership */
if(r_stat >= 0)
if(statb.st_uid != geteuid())	/* the file is not belonging to me */

/* the only definite test, whether the file is writable for me */
if( (fd = open(filename, O_WRONLY | O_APPEND)) >= 0){	/* yes */
close(fd); /* close without writing: mtime stays unchanged */
errno = s_errno;	/* restore errno for suppressing errors of utimes */
r = 0; /* return successfully */
}
}

return(r);
}


----------

