On Mon, Dec 8, 2008 at 4:20 PM, Greg Freemyer
All,
I'm having troubles with office docs that live on a SAMBA share.
As of a week or two ago, some (most? all?) of the docs I edit won't allow me to update them because they are claimed to be read-only.
ls -l does not show that.
I can work with local docs based on my limited tests. (most of the docs I need to edit are on shares).
I'm running OO 3.0 (build 3.0.0.3.5), I think from the OBS stable repository.
Who owns the samba share (as it is mounted on your box)? This is almost certainly a permissions problem in the mounting of the share. It also matters how and who mounted it on your box, and if you are trying to manage permissions on your end (from your box) or from the samba server's end. Managing from your end means you have to have the same UID and GID on both boxes (like it was nfs). This is seldom workable in a mixed environment, and I really don't know why it is the standard. Allowing the samba server to manage it means that your login to that box determines the permissions based on the settings in server, and your local uid/gid are not really involved. Quoting man mount cifs: If the CIFS Unix extensions are negotiated with the server the client will attempt to set the effective uid and gid of the local process on newly created files, directories, and devices (create, mkdir, mknod). If the CIFS Unix Extensions are not negotiated, for newly created files and directories instead of using the default uid and gid specified on the the mount, cache the new file's uid and gid locally which means that the uid for the file can change when the inode is reloaded (or the user remounts the share). nosetuids The client will not attempt to set the uid and gid on on newly created files, directories, and devices (create, mkdir, mknod) which will result in the server setting the uid and gid to the default (usually the server uid of the user who mounted the share). Letting the server (rather than the client) set the uid and gid is the default.If the CIFS Unix Extensions are not negotiated then the uid and gid for new files will appear to be the uid (gid) of the mounter or the uid (gid) parameter specified on the mount. perm Client does permission checks (vfs_permission check of uid and gid of the file against the mode and desired operation), Note that this is in addition to the normal ACL check on the target machine done by the server software. Client permission checking is enabled by default. noperm Client does not do permission checks. This can expose files on this mount to access by other users on the local client system. It is typically only needed when the server supports the CIFS Unix Extensions but the UIDs/GIDs on the client and server system do not match closely enough to allow access by the user doing the mount. Note that this does not affect the normal ACL check on the target machine done by the server software (of the server ACL against the user name provided at mount time). So: If it is your workstation, noperm is probably what you want, but that would not be the best choice for a server mounting a remote samba share for all users of that server. -- ----------JSA--------- Someone stole my tag line, so now I have this rental. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org