Results 1 to 4 of 4

Thread: Problems backing up windows machine to suse linux 13.1

  1. #1

    Default Problems backing up windows machine to suse linux 13.1

    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.

    How do I get around this?

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    15,668
    Blog Entries
    3

    Default Re: Problems backing up windows machine to suse linux 13.1

    Quote Originally Posted by svetter88 View Post
    How do I get around this?
    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.

    Here's an entry that I am using:
    Code:
    /dev/disk/by-id/ata-WDC_WD10EZEX-75ZF5A0_WD-WCC1S1730155-part5 /windows/C           ntfs-3g    ro,noauto,users,uid=1001,gid=users,fmask=133,dmask=022,locale=en_US.UTF-8 0 0
    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.
    openSUSE Leap 15.3; KDE Plasma 5.18.6;

  3. #3

    Default Re: Problems backing up windows machine to suse linux 13.1

    Quote Originally Posted by nrickert View Post
    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.

    Here's an entry that I am using:
    Code:
    /dev/disk/by-id/ata-WDC_WD10EZEX-75ZF5A0_WD-WCC1S1730155-part5 /windows/C           ntfs-3g    ro,noauto,users,uid=1001,gid=users,fmask=133,dmask=022,locale=en_US.UTF-8 0 0
    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.

    Thank you!

  4. #4
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Problems backing up windows machine to suse linux 13.1

    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.

    HTH,
    TSU

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •