"Share Folder" in right-click menu does not share ntfs drive folders

I think this might be more of a problem with gnome-vfs. Please correct me if Im wrong.

Thanks
chuck

Hi Charlie
I wasn't able to reproduce this issue, works fine for me, this under a clean install of Hardy Heron. Could you please try to reproduce this issue with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed release. You can find out more about the development release at [WWW] http://www.ubuntu.com/testing/

Thanks in advance

just to be absolutely sure, you're using shares-admin from gnome-system-tools to do this, right?

I'm not at the computer in question at the moment, when I get home I will boot with the Hardy Heron Live CD, and attempt to share a folder on my ntfs drive. I'm afraid I can't tell you the name of the application that shares the folders, just that it launches when I click "Share folder" in nautilus' right-click menu.

Hello,

I can confirm this. Right-Clicking on a Folder on a NTFS-Drive opens the Folder Sharing Settings. Clicking Create Share gives the information, that Nautilus needs to add some permissions to my folder in ordner to share it. Clicking Add the permissions automatically does not work. Error message:

Could not change the permissions of folder "xyz".

# /dev/hda4
UUID=35A24A8B2B97FBDB /media/hda4 ntfs defaults,umask=007,gid=46 0 1

regards,
Maximilian

I Confirm, i have attached some screens of error.

log:

drwxrwx--- 1 root plugdev 20480 2008-03-31 08:23 sda1

waldecir@xxxxxxxxxx:/media$ mount

/dev/sda1 on /media/sda1 type fuseblk (rw,nosuid,nodev,noatime,allow_other,default_permissions,blksize=4096)

what worked for me:

Just start Nautilus as root. "gksudo nautilus" an then set your wanted sharing options.

I can also confirm this bug. Sharing NTFS simply does not work out-of-the-box on Hardy due to the permissions errors.

Using "gksudo nautilus" worked for me, as well as adding "uid=1000" to the options column in /etc/fstab. However these really are just work arounds, and neither method is ideal.

What more information is necessary to get this bug to be Confirmed instead of invalid? Several people have said this is an issue for them, and I see no requests for additional information.

Also, should this not be of higher priority? Many users who still need to use windows probably have files and documents stored on NTFS drives which they need to share. This is one of the most glaring bugs I am have seen in Hardy.

I went through the "upgrade to hardy" process a little over a week ago and I run into a serious problem which is very much related to this.

I basically have two 500GB USB harddrives formatted as NTFS connect to my Ubuntu machine. On these drives I have over 20 different SMB shares each and the upgrade process automatically DELETED ALL MY SHARES WITH NO WARNING WHAT SO EVER AND WITH NO CHANCE OF RECOVERY. This caused a some serious downtime problems for me. On top of that, once I got hardy up and running I could not even fix these problems because hardy will, as the bug explains, not let you share files owned by root due to the "usershare owner only = False" flag being default in Ubuntu. Imagine all the people that are running small servers with NTFS partitions like I do. This is not a nice experience for them during upgrade.

The bug that I filed about the broken upgrade process was closed as a duplicate of this bug (even though they are in fact slightly different).
Please have a look at my original bug report here:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/214714

Sharing folders on NTFS drives is an important use case and it worked perfectly in previous versions of Ubuntu (so this is a regression and people are very unforgiving about regressions). I'd very much give my vote to fixing this before (or soon after) the hardy release.

I marked your bug as a duplicate because the root issue seemed the same. If this was in error I apologize.

I certainly agree that there needs to be a warning on upgrade that shares may be lost. It may be too late to fix the actual regression before Hardy's release, but there really should be a warning so people don't run into this blindly.

Adding "usershare owner only = False" did not work for me; perhaps I did it incorrectly.

this problem can be solved by having the fstab line as
# /dev/hda4
UUID=35A24A8B2B97FBDB /media/hda4 ntfs defaults,umask=000,gid=46 0 1
instead of umask=007

000 gives read write permissions to everyone (ie the same as 777 in chmod). the last digit is for the "others" which included samba. i think this should be the default mount line on hardy. Is there any reason why you wouldnt want this?
ntfs is a shared partition as it has no concept of permissions, so allowing "others" to read write makes sense. it should be as permissive as possible as there is no concept of any security (note that samba itself then has the option in the gui to allow user looking at your share to edit it, by setting 000 users on the network cant write to your files unless samba lets them too)
if not this then samba should be added to the group with gid=46, or whatever is necessary
adding "uid=1000" is surely wrong, as this is just for you as a user, so doesnt work on shared systems, as only one user can acess the drive

the gui correctly tells you you need to add "usershare owner only = False", but you also need to give samba permission to read the drive, which is not done by default, and which the gui does not tell you. this is probably the problem for "Waldecir Loureiro dos Santos Filho" and "raptor45"
anyone agree?

I can also confirm this. It is not possible to share NTFS folders on samba. If I use gksu nautilus, it is possible to share it and show up on the network, but the folder cannot actually be opened.

this bug report is confusing several issues into one, and the initial poster mixed up uid and umask in a confusing way.

to summarise:
1)have uid of your user means you can share the folder without having to edit /etc/samba/smb.conf (or you could just share it running nautilus in root ie gksu nautilus).
2)having umask of 000 means computers on the network can actually access the share (the dialog about automatically changing permissions does not work as ntfs/vfat doesnt support individual file permissions, so if it wants to change permissions it has got to edit /etc/fstab which it doesnt know how to do).

i made a new bug report bug #255391, which pulls out one of the issues (the umask one) which at least endolith seems to be suffering from. this might be more useful

'net usershare' returned error 255: net usershare add: cannot share path /media/500/Downloads as we are restricted to only sharing directories we own.
 Ask the administrator to add the line "usershare owner only = False"
 to the [global] section of the smb.conf to allow this.

As Carasof's reply details, that message is now displayed in the Sharing Options dialog, and following it's instructions allows you to share the folder successfully.

However, this is not a very user-friendly way of allowing NTFS drive sharing, would shipping the default smb.conf with "usershare onwer only = false" be a better long term solution?

A better method would simply be a confirmation box that popped up when sharing an NTFS folder that explained the security risks of enabling this setting, asking for confirmation, and then doing the smb.conf change automatically. Every time I have to go into a config file when using Ubuntu, I feel it has somehow let me down.

I also confirm this bug.
After changing the ntfs partitions in /etc/fstab from umask=007 to umask=000
and adding the line: "usershare owner only = false" to the global section in /etc/samba/smb.conf my problem was solved.
But a normal user won't understand this at all, and we want to create a userfriendly linux distribution right?

The default setting is there for security reasons. Usershare is, by default, limited to sharing a directory that you own.
I agree that nautilus-share could be a little more user-friendly and detect this special case, but it's not a bug.

On Monday 30,November,2009 03:24 PM, Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug:
>
> Binary package hint: samba
>
> Problem:
> When either right-clicking in nautilus or using the Shared Folders application in the Administration menu, I cannot share a folder on an ntfs-mounted drive. When I attempt to, an error message pops up saying something like "cannot access file/folder". The folder is not shared, and I am given no indication as to how to resolve the problem.
>
> To reproduce:
> - Have an ntfs formatted drive in your system
> - Have ubuntu auto-mount it with default partitions (it should appear on your desktop)
> - Attempt to share a folder in this drive
>
> My workaround:
> After much digging into a solution, two problems became apparent with Ubuntu sharing: 1. Drives formatted as ntfs (possibly others) and mounted by Ubuntu (with default permissions - UID = 007 in my case) cannot be accessed by samba, and 2. Folders shared this way require a terminal command to be entered (smbpasswd) in order to allow the share to be accessed. I think 2. is being addressed in another bug, but 1. is still a problem for me and other users.
>
> I eventually worked out that the permissions were wrong for samba to be
> able to access the drive, and so changed the UID in my fstab to that of
> my user account. While this worked like a dream, I have a feeling that
> these drives would now be inaccessible if I created another user on my
> machine.

I have a feeling that at least one of the "UID" occurrences should actually be
umask, though I'm not sure. Could you look into it and correct as necessary? I'm
having some difficulty understanding exactly what you mean here.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Why is NTFS drives mounted with "root" as the owner of all the files? When I connect a drive with my Files I want them to be owned by me, not root?

@Martin: probably because you tell the system to mount it like that. I suppose it's defined in a system-wide /etc/fstab and without any specific option it will mount at boot-time as owner root (can't guess you will want to use it as user foo). In all cases, that's a separate issue.