Arch Linux

gigs_42

Member

Registered: 2010-05-26

Posts: 3

[solved] Samba Strangeness (Don't enable NTFS compression)

Hey all,

Accessing samba shares via windows 7 professional on my arch box is acting strange.  On the one hand, I am able to (from win7) browse my shares, copy from my shares, right-click and create new files of any type, open, edit and save files that are already there, so one would think things are all well and good.  However, when I attempt to cut/copy and paste items from windows onto the share, permissions (apparently at least) blow up in my face and it refuses to do so, giving me a 'You need administrator privileges to make changes to this folder' message.  This also occurs when programs on the win7 machine attempt to write to the shares (ie backup software   )

I've gone through I don't know how many different smb.conf configs (allowing guests, changing the security to user instead of share, etc) as well as fstab permissions (gids, no gids, uids, no uids, wide open umask like I have now, etc) and everytime I get the same results.  I've enabled and disabled lanman/ntlm respectively - again with the same results (oh, and yes I've been restarting the samba server for each config change)  I've also completely removed samba and everything it left behind to start with a clean samba install, to no avail.  Further, (I'm new to arch) I had a samba server setup on slackware 13.0 on the machine that I'm running arch on now and was able to access it perfectly well using my win7 lappy.  I'm completely perplexed as to what the problem is (or could be) and I'm at a loss for where to begin figuring it out - thoughts?

 
Samba config file created using SWAT                                          
# from UNKNOWN (127.0.0.1)                                                      
# Date: 2010/05/26 23:33:12                                                     

[global]
        workgroup = LEGION
        server string = Samba Server on Punisher
        security = share
        log file = /var/log/samba/%m.log
        max log size = 50
        dns proxy = No

[ISOs]
        comment = Awesome Linux ISOs
        path = /mnt/backups/ISOs
        read only = No
        writable = Yes
        guest ok = Yes

[More shares Identical to this one]
...

As ugly as it is, I have permissions currently wide open, trying to figure out what the problem is...
/etc/fstab line pertaining to the relevant drive where all of my shares are living

...
/dev/sdb1 /mnt/backups ntfs-3g gid=users,umask=0000 0 0
...

Oh, and it's an ntfs drive because I'm dual booting with xp

*Edited title to show as solved.

Last edited by gigs_42 (2010-05-30 02:03:14)

Sin.citadel

Member

Registered: 2008-01-22

Posts: 267

Re: [solved] Samba Strangeness (Don't enable NTFS compression)

it could be a NTFS permission error, try creating a share in the ext3/4 file system and see if you can create files in it.

gigs_42

Member

Registered: 2010-05-26

Posts: 3

Re: [solved] Samba Strangeness (Don't enable NTFS compression)

Thanks for the response.  Setting up a native share (JFS, not that it matters) with open permissions, I was able to transfer things appropriately.

Interestingly, I've noticed that if I try to copy files from the windows machine to the ntfs samba share, it succeeds in initially allocating the file - even for very large ISOs (~5gigs) - it just fails to transfer any data into said ISO file due to some sort of apparently ntfs permissions problem.

So to summarise where I'm at: 
Files/Directories on the ntfs share can be edited and saved appropriately
Files/Directories can be created by right-clicking in windows explorer -> new -> whatever and can then be edited and saved
From the win7 machine, Adobe Reader -> Save Copy -> save to the ntfs share actually works as well, even though copying/pasting the same pdf doesn't

Copy/paste files onto the share in windows DOESN'T work.
Other applications (Backup software in particular) DOESN'T create/edit/copy files, except for initial allocation, after which it blows up asking for admin privileges to make changes to the shared folder...

Seems to me that some apps/functions in windows are using one method for accessing the share (or checking some perm setting) while others aren't since in some cases everything works as expected on the ntfs share...perhaps it's a windows settings problem? (Imagine that...)

gigs_42

Member

Registered: 2010-05-26

Posts: 3

Re: [solved] Samba Strangeness (Don't enable NTFS compression)

Fixed the problem - turns out it wasn't Windows (exactly) but some settings I had on the NTFS volume.  In Windows, I right clicked the drive -> properties ->  DESELECT compress volume and indexing.  Voila, problem solved.  I also ran chkdsk /f on the thing to make sure everything was kosher, it fixed a couple errors it found (not sure if they were related or not) but the share is writable as expected now.

From the NTFS-3G FAQ that gave me the needed hint:

Why can't I read or modify some files?

NTFS supports built-in, transparent compression and encryption of files and directories on the file system level. Reading and writing transparently compressed files are supported but overwriting is not, and reading or writing encrypted files are not supported at the moment. Please note that compressed files, like .zip, .gz, .rar, etc, can be freely modified because they are compressed on the file, not on the file system level.

Workaround: Decrypt the needed files on Windows.

The moral of the story is - don't enable NTFS compression if you want to use NTFS-3G all the time