Page 7 of 8

Posted: Mon 21 Oct 2013, 19:42
by rcrsn51
Because this is an NTFS partition, try this mount command instead.

Code: Select all

ntfs-3g /dev/sdc4 /mnt/sdc4

Posted: Mon 21 Oct 2013, 21:04
by toronado
rcrsn51 wrote:Because this is an NTFS partition, try this mount command instead.

Code: Select all

ntfs-3g /dev/sdc4 /mnt/sdc4
This works. Thanks.

mounting shares

Posted: Sat 26 Oct 2013, 04:04
by toronado
Does it make any difference, as far as Samba-TNG is concerned, whether commands to mount shares are in rc.local or samba-autostart ?

Posted: Sat 26 Oct 2013, 13:14
by rcrsn51
Maybe. If the share was on something like an external USB drive, you might need to wait until Startup to ensure that it was properly detected.

Posted: Sun 27 Oct 2013, 10:15
by toronado
rcrsn51 wrote:Maybe. If the share was on something like an external USB drive, you might need to wait until Startup to ensure that it was properly detected.
OK, thanks.

using Windows backup software fails

Posted: Sun 27 Oct 2013, 10:49
by toronado
I can copy files manually from Windows (drag and drop in Windows explorer) to Samba shares in Puppy without any issues.

But when attempting to use backup programs in Windows to copy files, network access to the server is denied.

Posted: Sun 27 Oct 2013, 12:15
by rcrsn51
Are you using authentication? In Windows Explorer, do you need to enter a password in order to access the share?

Does your backup software let you add any options when connecting to the Puppy server?

There is a way in Windows to assign a drive letter, like F:, to the share. That might be a better way for your backup software to access it.

Posted: Mon 28 Oct 2013, 07:53
by toronado
rcrsn51 wrote:Are you using authentication? In Windows Explorer, do you need to enter a password in order to access the share?
I'm not currently manually entering credentials when browsing the Puppy server in Windows Explorer. Windows was previously prompting for credentials. I may have ticked a checkbox for "remember my credentials" at some point. Or it may just be that I changed something in the smb.conf which enables access without authentication. So I'm not really sure.
rcrsn51 wrote:Does your backup software let you add any options when connecting to the Puppy server?
It allows me to enter credentials for connecting to a network. I have tested it both with and without credentials. The software has a button you can press to "test connection". The test always says "success" regardless of whether credentials are used or not. It seems the connection may not be requiring credentials. Though again, not sure.
rcrsn51 wrote:There is a way in Windows to assign a drive letter, like F:, to the share. That might be a better way for your backup software to access it.
Per your suggestion, I mapped the network share to a drive letter and tried using it that way with the backup software. However, this method doesn't fix the problem I'm having. Incidentally, the backup software actually suggests that it would be "better not to use a drive letter" and that I should use the "\\[server]\[share]" method instead, but allows me to use the drive letter anyway if I so choose.

The server allows the backup software to scan (read from) the share during the initial file comparison phase of the backup routine. The problem I am having seems to occur when the backup software attempts to copy a file (write) to the share. When this problem occurs, access to the server via Windows Explorer also freezes up. After aborting the backup routine, there is a period of time (a minute or two) where no access to the server is possible, then access is restored.

Also I noticed something...
When mapped to drive letters, Windows shows my Samba shares as having the "NTFS" file system, even though in reality they are ext4. Is that normal?

Posted: Mon 28 Oct 2013, 12:22
by rcrsn51
toronado wrote:So I'm not really sure.
You probably enabled the "map to guest" line in the smb.conf. I would go back to the original configuration that requires authentication with root:woofwoof. Then try authenticating in your backup software.

If it still fails, I would try installing one of the full Samba packages.

Posted: Mon 28 Oct 2013, 20:47
by toronado
rcrsn51 wrote:You probably enabled the "map to guest" line in the smb.conf.
No, I'm not using guest access. I was referring to the fact that I need to have "force user = root" on the share otherwise I get permissions and "file in use" errors in Windows.
rcrsn51 wrote:I would go back to the original configuration that requires authentication with root:woofwoof. Then try authenticating in your backup software.
I found where Windows was storing my credentials and deleted them. Then I tried entering the credentials manually, both in Windows Explorer and in the backup software. However this didn't solve the problem.
rcrsn51 wrote:If it still fails, I would try installing one of the full Samba packages.
I suppose that is what I'll need to try next. Would I need to uninstall/remove Samba-TNG first, or just disable the auto-start function?

Posted: Mon 06 Jan 2014, 18:39
by ralplpcr
I was just wondering if a solution had been found to toronado's problem?

I've come across a similar problem, and it's got me somewhat stymied. Like toronado, I can copy/paste or drag/drop files from Windoze directly into the shared folder. But when I try to use a ripping program to save the output to the share, I keep getting weird messages - - such as "Disk Full". (There is currently over 500GB of free space on the drive)

I'm wondering if deleting the credentials is only part of the problem. I know that I was using the same drive letter previously when I had my shared drive set up under a (now crashed) Win2003 server - - could there be some other saved info that thinks it's still connecting there?

Great tutorial, by the way! I was able to set up a very zippy 3 drive Samba server and shared printer in no time flat. Certainly a lot easier and cheaper than rebuilding another Winblowz server! :)

Posted: Mon 06 Jan 2014, 19:06
by rcrsn51
I ran the following test.

1. I started a Samba-TNG server using the defaults, with authentication.

2. On an XP machine, I made a desktop shortcut to \\pupserver.

3. I logged into the server as root + woofwoof.

4. I ran Notepad and typed in something.

5. I selected Save as > Save in > My Network Places

6. I selected the TNG share, opened a folder inside and saved the file.

7. I repeated with several other apps. They all worked.

I have never tried to do it by assigning drive letters.

Posted: Mon 06 Jan 2014, 23:42
by ralplpcr
rcrsn51 wrote:I ran the following test.

1. I started....
Yup, that works fine, as do most other Windows-native programs. It's just something about this particular one that's being stubborn. Even after completely deleting my credentials and re-mapping the drive letter, I still can't get it to work right.

And of course, it's not network-aware... you can't just type "\\server\share\filename" or anything like that in the SAVE dialog. That's why I was mapping it to a drive when I still had my 2003 server running.

For now, running the program to save on my local drive and then copying to the server works. It's an annoying extra step, but I'd still rather do it than go through the hassle of reinstalling Windows. I'll keep poking around at the puppy Samba settings... maybe there's something there which can be tweaked?

Thanks for checking into it for me!

EDIT: fix typo, clarification

Posted: Tue 07 Jan 2014, 00:24
by rcrsn51
I expect that the problem is with your application. It is trying to find the size of the target drive as if it was a local drive. But the Samba server cannot report that information back to the application.

Maybe one the full-sized Samba packages would report its share size.

Posted: Tue 07 Jan 2014, 01:19
by ralplpcr
rcrsn51 wrote:I expect that the problem is with your application. It is trying to find the size of the target drive as if it was a local drive. But the Samba server cannot report that information back to the application.

Maybe one the full-sized Samba packages would report its share size.
Possibly? It's a very odd error message:

"The target drive does not have enough free space for this operation.
Cannot find the target specified"

Between the two, I can't determine if it's telling me it can't *find* the mounted drive (despite the fact that I manually navigated to it via the interface) or if it thinks there's not enough space (even though it shows nearly 500 GB free after selecting).

I am beginning to wonder if the issue is in how I have the smb.conf set up? I had 3 large drives in my old Win2003 server, which already had tons of data stored on them. Rather than share them individually, I created a single folder, and mounted each drive as a subfolder underneath that single folder.

Code: Select all

---movies (drive Z: )
      |
      |--disk 1
      |
      |--disk2
      |
      |--disk3
I only set "movies" as the share in smb.conf. I can easily view, open, read, & write to each of the subfolders (drives) via the Windows explorer. But when I try to use the ripper's SAVE dialog, I get that odd error message. It could be that it's reading the available space as what's in the "movies" folder.... which is on my USB drive, so not a lot.

Perhaps I need to figure out how to share the disks as subfolders in smb.conf? Of course, I could just share them individually... but I'm trying to keep it organized all under 1 share if possible. :wink:

I'll try sharing them individually to see if that fixes the problem. If it does, then I just need to figure out how to make my smb.conf organize them better.

Good thing I enjoy a challenge, huh?

Posted: Tue 07 Jan 2014, 23:01
by ralplpcr
ralplpcr wrote:<snip>
I'll try sharing them individually to see if that fixes the problem. If it does, then I just need to figure out how to make my smb.conf organize them better. </snip>
That was the issue. As soon as I set "disk3" to have it's own share (and mount under it's own drive letter), the error message went away. :D

Of course, now I have some random "network resource has gone away" errors... but I don't think that's Samba's fault. More than likely because I've got it temporarily hooked up via wireless until I can get it running and moved back to it's normal home.

Anybody have ideas how to tweak smb.conf to keep them under a single share?

Posted: Wed 08 Jan 2014, 01:20
by rcrsn51
What is the combined size of the three drives? Maybe the movies share has exceeded some allowable maximum.

Posted: Wed 08 Jan 2014, 02:39
by ralplpcr
The three drives are as follows:
1tb, 1.5tb, 1tb

They're formatted NTFS, so overall available size is around 3.1tb.

Although it's not *exactly* how I want it, as long as I set each individual drive as a share in smb.conf, it does work well.

I don't see any limit anywhere within the share, but I am still somewhat of a novice with Linux. Any suggestions where I might check for this limit?

Posted: Wed 08 Jan 2014, 04:07
by rcrsn51
ralplpcr wrote:They're formatted NTFS, so overall available size is around 3.1tb.
That would seem to be the answer. You have a non-network-aware application trying to access a single drive Z: that is exceeding the standard 2 TB limit for Windows.

Maybe for the purposes of your burning program, you could map Z: to movies/disk3.

Posted: Wed 08 Jan 2014, 23:28
by ralplpcr
rcrsn51 wrote:You have a non-network-aware application trying to access a single drive Z: that is exceeding the standard 2 TB limit for Windows.
I thought of that, but it doesn't make sense how it worked that way when I had them running in the 2003 server using that setup. If that's the case, then I wonder what will happen when I replace one of those drives with a 3TB drive, as I was planning to do in the near future? Will I be able to "see" it at all?

For that matter, I certainly hope that Puppy can mount it - - being only 32 bit. I had heard that kernel support was present for a few years now for larger drives, but worst case I can migrate from Slacko 5.6 to something like FatPup.

In any case, I do appreciate your help and patience! :) Even if I can't make it work exactly as I used to have it, I'm still quite pleased that it's working... and I can adjust to having to do things a little differently.