I am trying to backup a windows 7 machine to my open suse linux 13.1 machine and apparently having a security issue that I can’t pin down. I have a partition formatted as a HPFS/NTFS. Been into YAST and setup a user ID. And added a user and password for the SMB by using the smbpasswd program. Further I have a directory setup for the windows machine.
On the Windows 7 machine I can go into the file directory via My Computer, then into network, choose the machine, enter the username and password, then drill down to the directory where this machine is to store it’s backups. Win running windows backup I again choose the linux machine, and then the partitions. Then I enter the username and password and the back starts but quickly ends with “The specified network location cannot be used.” Verify the path points to correct a network location and that the supplied credentials can be used for write access to the folder.
In looking at the head directory it has permissions of drwxr-xr-x root users. The windows 7 machine’s userid is in the users group but still the folder premission is not set to write and can’t do that for partition that is NPFS.
I’m not sure that I fully understand the question. However …
For an NTFS file system, you can use “uid=number” and “gid=number” in the mount options, so that linux sees it as owned by that user and group. There’s also a “umask=” mount option (actually, an “fmask” and a “dmask”). You can put all of those in “/etc/fstab” if you are automatically mounting this partition.
That entry isn’t what you want, because I default to not mounting, and to mounting read-only unless overridden. But it should give you an idea on the possibilities.
Thought I spelled out the situation well. Anyway, this gives me something to work with. Samba from my understanding will not override the what the security settings are for the partition/directory. What you supplied gives me something to look into and try.
Am assuming that you are trying to backup to a share using the path.
An alternative which is often far more reliable is to first mount the share as a drive.
There are several advantages…
The drive can be configured to mount on boot and no “on demand” so it’s already available when the app wants to use the network share. Avoids many possible network anomalies.
You’re certain the drive and share work. By first mounting the share as a drive you can test writing to the mounted drive beforehand.
Some apps have issues connecting to network resources. Mounting a share (or other remote resource) as a local drive means the app sees the remote resource as a local resource.
As for the security issue you’re looking at, it can be complex.
Unlike the local file system, you need to consider
The security context of the app or User
The file permissions on the Server
The share permissions on the Server
If the client and server are both part of a Network Security system (like LDAP) then permissions are typically managed at the network level, but if you don’t have network security installed (ie the User logs into the Local Machine), then you need to configure local file and share permissions on the Server and configure accordingly on the client machine.