Re: [libreoffice-users] Re: [Not to group] Re: files on network shares not opening. Own ones are ok?

On 2014-09-01 06:54, Jim Seymour wrote:
> On Mon, 01 Sep 2014 06:41:44 +1200
> Steve Edmonds <steve.edmonds@ptglobal.com> wrote:
>
> [snip]
> > Did you notice the permissions and owner on the server of the older
> > files and newer ones. Did the permissions change when you copied
> > the files. There is also a tick box in options>General to use LO
> > open/save dialogue boxes. I don't know if that changes anything.
> [snip]
>
> The originals had owner execute permissions, whereas the copies did
> not.  The copies ended up with current modification dates.
> Otherwise permissions and every other aspect of directory and files
> were unchanged.
Hi.
Some guff follows, but it would be interesting to see if the owner 
executable made a difference if its somehow got mixed in with DOS 
compatibility settings.
Another possibility might be to ask on the devs list how network file 
access in LO may differ from what you find is working for other files.
I have this vague recollection on our server 2 machines ago (older 
version samba) that I could open a LO file by double clicking in the 
file browser but not in the LO file open dialogue, or vice versa. Or may 
be it was I could open a file on a network share mounted locally but not 
by browsing the network. This all came right when I updated the server 
and started with cifs.
Steve

Note that there is no bit to specify that a file is executable. DOS and 
Windows NT filesystems identify executable files by giving them the 
extensions .EXE, .COM, .CMD, or .BAT.

Consequently, there is no use for any of the three Unix executable bits 
that are present on a file in a Samba disk share. DOS files, however, 
have their own attributes that need to be preserved when they are stored 
in a Unix environment: the archive, system, and hidden bits. Samba can 
preserve these bits by reusing the executable permission bits of the 
file on the Unix side - if it is instructed to do so. Mapping these 
bits, however, has an unfortunate side-effect: if a Windows user stores 
a file in a Samba share, and you view it on Unix with the |ls| |-al| 
command, some of the executable bits won't mean what you'd expect them to.

Three Samba options decide whether the bits are mapped: |map| |archive|, 
|map| |system |, and |map| |hidden|. These options map the archive, 
system, and hidden attributes to the owner, group, and world execute 
bits of the file, respectively. You can add these options to the 
|[data]| share, setting each of their values as follows:

[data]
        path = /home/samba/data
        browseable = yes
        guest ok = yes
        writeable = yes
        map archive = yes
        map system = yes
        map hidden = yes

After that, try creating a file in the share under Unix - such as 
|hello.java| - and change the permissions of the file to 755. With these 
Samba options set, you should be able to check the permissions on the 
Windows side and see that each of the three values has been checked in 
the Properties dialog box. What about the read-only attribute? By 
default, Samba 2.0 sets this whenever a file does not have the Unix 
owner write permission bit set. In other words, you can set this bit by 
changing the permissions of the file to 555.

We should warn you that the default value of the |map| |archive| option 
is |yes|, while the other two options have a default value of |no|. This 
is because many programs do not work properly if the archive bit is not 
stored correctly for DOS and Windows files. The system and hidden 
attributes, however, are not critical for a program's operation and are 
left to the discretion of the administrator.



--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted