Can't share a mounted dd image.

[DrCR]

A drive running WinXP recently failed on me. All the data is on a Lenny NAS server though, so no real data lost. I have an old dd image of the WinXP partition, so I thought I would mount the dd image on the nas and then share it via samba so I could grab a config file or two as needed while booted into the new WinXP install I'm working on.

I'm off site at the moment, but here's basically what I did:
# mkdir /mnt/temp
# chown joeuser:joeuser /mnt/temp
# mount /mnt/raid/backups/oldWinXP.dd /mnt/temp -t ntfs -o loop,ro
and basically cloned a working smb.conf entry for temp from one for the raid, where all connections get password="" joeuser access.

I confirmed access to internals of the mounted dd image when in the server, but attempting to access the files via samba from the WinXP install, however, gets a permission error where I can not even view the files. No problems with the raid share though.

A ls -lah indicates joeuser:joeuser is not the owner of directory temp when the dd image is mounted...but is when it is not mounted. Not only is root:root the owner when mounted, but others have no access. I ran chmod o=r temp to allow read access and added umask=000 to the mount options, but I still can not view the mounted files in temp from the WinXP.

Any thoughts?

Only thing I can think of trying right now is making a fstab entry with -o users and mounting while logged in as joeuser instead of root and see if that works. :\

Thanks,
DrCR

[bwkaz]

A ls -lah indicates joeuser:joeuser is not the owner of directory temp when the dd image is mounted... Right, because the ntfs (or ntfs-3g) filesystem drivers don't support Unix style permissions. (vfat is the same way.) Read-only might work, but I wouldn't count on it.

(Also, part of the difference is the mount itself. The permissions and ownership of the mount point change to whatever the mounted FS is storing for its root directory -- which in the case of vfat or ntfs or ntfs-3g, is root/root, 0500 (IIRC), since that's what it uses for every file and directory.

What you need to do is tell the filesystem driver to fake a different owner and/or group, and/or fake different permission bits. The ntfs filesystem uses the "uid", "gid", and "umask" mount options for these. Assuming you need your normal user to have read access, but nobody else, you can probably get away with something like this. First find out your UID (not as root; root's UID is always zero so there's no point in seeing what it is ;)):

id -un

Then, use that value below (this part needs to be done as root):

mount -t ntfs -o loop,ro,uid=value-from-above /whatever/path/to/image/file /wherever/you/want/to/mount/it

Just replace the "value-from-above". :)

(You could also simply mount -t ntfs -o loop,ro,umask=0000 /blah/blah /blah/blah, but uid is probably a bit more secure.)

If that still doesn't work from XP, look at the ownership and permissions on the Linux side again. (I.e., troubleshoot from a lower layer. When you test from XP, there are about 100 extra layers between you and the actual filesystem permissions -- XP's own cruddy security model, Samba's security model, and actual FS permissions compared to the user that smbd runs as.

(Actually that last bit might be the whole problem, too. What are the permissions on the files (and directories) that are sharing properly? Are they owned by a specific user (or group), or do they just have world permission?)

I ran chmod o=r temp to allow read access Same issue: ntfs, ntfs-3g (and vfat) don't support permissions. So you can't change them. ;)

and added umask=000 to the mount options, but I still can not view the mounted files in temp from the WinXP. Assuming "to the mount options" means "in the /etc/fstab file" (;)), the issue there was that an explicit mount doesn't use /etc/fstab.

If that isn't what you meant, and you've already tried what I had in the parens above, then it still may work to use uid (and/or gid). (Also, the messages that the kernel logs would be helpful: dmesg | tail -n 40 or so should give you the last few of those.)

[DrCR]

I had tried the following without success:
mount /mnt/raid/backups/blah.dd /mnt/open -t ntfs -o loop,ro,users,umask=003
Am I supposed to use umask=0000? Never seen umask with four 0s. I assume that was a typo.

...success!
Hum, it worked with umask=000:
mount /mnt/raid/backups/blah.dd /mnt/open -t ntfs -o loop,ro,users,umask=000

With umask=003 and 000 respectively:
dr-xr-xr-- 1 root root 4.0K 2008-05-01 23:20 open
dr-xr-xr-x 1 root root 4.0K 2008-05-01 23:20 open
Noone is w as it's mounted -o ro, obviously, but what's really odd is that apparently executable permission is required for samba sharing of MS filesystem files?! :eek:

At least it's working for my purposes. Thanks! :D

DrCR

[furrycat]

If a directory isn't executable you can't chdir to it.

[bwkaz]

Am I supposed to use umask=0000? Never seen umask with four 0s. I assume that was a typo. Not a typo, but it doesn't matter. I'm just used to specifying permission bit collections in octal, which requires a leading zero (so e.g. 111 would not work, but 0111 would). But if the value is zero, then it doesn't matter. (Zero is the same whether you're parsing it in decimal, hex, octal, binary, or any other base.)

That's why I do four digits: to leave an extra one for the leading zero. :)

But yes, as furrycat said: you need execute permissions on directories. If you don't want execute permissions on files (which is slightly more secure, but over Samba probably doesn't matter), then you probably want to specify an fmask and dmask individually (these are "umask for files" and "umask for directories", respectively). I'd probably use either 0111 or 0333 for fmask, and either 0000 or 0222 for dmask, if you want to do that.

Or, since it's working and it's temporary, you can likely just leave it as-is. ;)

[DrCR]

Awesome, thanks guys! Just goes to show how much I have to learn.

Thanks again! :D

[cybertron]

Awesome, thanks guys! Just goes to show how much I have to learn.
Heh, not to worry. It wasn't that long ago that I thought I was hot stuff setting up a public directory for a group project, only to discover that nobody could cd into the directory. At the time I didn't know execute permission was required for directories to be viewed either.:)